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Foreword 



The purpose of Understanding DTCQM 3.0 is to offer those inter- 
ested in digital imaging communications in radiology an overview of 
the complex world of DICOM. DICOM is an acronym for Digital 
Imaging Communications in Medicine. 

DICOM is the new standard the major providers of diagnostic 
modalities and PAC systems have agreed to use for sharing image 
and digital data between products from different vendors. It has been 
endorsed by the American College of Radiology (ACR) and the 
National Electrical Manufacturer's Association (NEMA). 
Combined, these two groups make up ACR-NEMA. DICOM was 
developed by ACR-NEMA, academia, and members from many 
vendors' technical communities. It has been under development for 
over ten years. 

It is not possible for any single book this size to explain in detail how 
DICOM works. The standard is hundreds of pages in length and, as 
with most standards, is written with a technical focus. It is not neces- 
sary for a user, physician or administrative director to fully under- 
stand the inner workings of this standard. 

Yet, with all the talk by vendors and in our journals, there is tremen- 
dous curiosity about DICOM. We believe this book will describe at 
a high level what DICOM is, what the various parts of DICOM mean 
and what you need to know as we enter into the new world of 
DICOM. 

The most important thing to realize is that, as required by the 
purchasers of complex hardware and software solutions, DICOM 
was created for the benefit of users, not for the benefit of vendors and 
suppliers. 

Certainly the path of least resistance and cost would have been to 
continue to use the proprietary languages and networks of the '70's 
and '80's. Back then, diagnostic image output was in a format or 
language unique to each specific vendor. That meant if you 
purchased a digital imaging (or PACS) network, you were locked 
into that vendor's modalities with the purchase of each new device 
that should be connected to the existing network. The risk of making 
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an improper decision was very high. Customers would have been 
locked out of innovative solutions created by other vendors and their 
ability to negotiate price with your supplier would have been greatly 
reduced. For these reasons, DICOM was needed. 

DICOM is changing the ways of the past and definitely for the 
benefit of the consumer. With DICOM and the new "open systems" 
solutions touted by nearly all vendors, you can now purchase modal- 
ities from one vendor, workstations from another, connect any 
printer to the network and purchase one archive for the entire depart- 
ment. 



DICOM is ratf... 

• the answer to all your networking problems 

• a network architecture 

• available for all older modalities 

• a static standard 

• easy to understand! 

This book will not make anyone a DICOM expert, nor will it teach 
anyone how to build a DICOM interface. We hope that this book will 
offer what the interested person needs to know to be comfortable and 
conversant with DICOM. 
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Chapter 1 : Introduction 



What is DICOM? 

Digital Imaging Communications in Medicine, or "DICOM," is a 
standard that is a framework for medical imaging communication. It 
is based upon the Open System Interconnect (OSI) reference model, 
which defines a 7-layer protocol model. It is an "application-level" 
standard, which means it exists inside layer 7 (the uppermost layer). 

DICOM was developed by the American College of Radiology 
(ACR) and the National Electrical Manufacturer's Association 
(NEMA), with input from various vendors, academia, etc. It is 
referred to as "version 3.0" because it replaces versions 1.0 and 2.0 
of the standard previously issued by ACR and NEMA, which was 
called the "ACR-NEMA" standard. 

DICOM provides: 

• standardized formats for images 

• a common information model 

• application service definitions 

(see "Service Classes" in Chapter 3) 

• protocols for communication 

(see "Services and Protocols" in Chapter 3). 



Note: Part 1 of the DICOM 3.0 Specification document contains 
historical information, as well as an outline of the goals of 
and future expectations for the standard. 
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Why the New Standard? 

ACR and NEMA set out to develop this new standard for the 
following reasons: 

• To make it applicable for a network environment (previously, it 
was for point-to-point connections only) 

• To address the subject of conformance (set up minimum require- 
ments for those who want to claim conformance to the standard). 

• To introduce explicit information objects (introduce objects for 
studies, reports, etc., in addition to images) 

• To achieve the goal of interoperability between equipment from 
multiple vendors' equipment. 



What are the Differences? 

There is a philosophical difference between the ACR-NEMA stan- 
dard and DICOM 3.0. With ACR-NEMA, the goal was merely 
exchanging images between equipment from multiple vendors. The 
goal of DICOM is to make that equipment interoperable. It provides 
for this by introducing the concept of explicit information objects. 

For example, say a modality is sending images to a picture archiving 
and communications (PACS) system, which is going to store the 
images. The details of how the PACS system accomplishes this don't 
have to matter to the modality; the modality just wants the PACS to 
do its job. Therefore, the modality can just put all of its image and 
demographic data into one neat package or composite objecu and 
"tell" the PACS to store it This simple exchange of images is what 
ACR-NEMA provided. (This is also still available with DICOM 
3.0). 

By contrast, however, say the modality wants to print an image on a 
printer. The way the printer handles the information is very impor- 
tant to the modality, because it affects the way the image is tones- 
caled, formatted, etc. With DICOM 3.0, the modality can control 
these things by using explicit information objects that correspond to 
film sessions, film boxes, image boxes, etc. 
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Chapter 1 : Introduction 



About This Book 

This book explains the different types of information objects and 
other components of DICOM, and tells you how to interpret the 
information in the DICOM 3.0 specification. It is intended to 
provide information an implementer needs to learn and understand 
how to use the new standard, assuming he or she is familiar with the 
way the previous ACR-NEMA standard functioned. 



Note: This book is based upon the version of the DICOM 3.0 
specification document that was distributed for ballot. 



The information in this book is organized into the following 
sections: 



Chapter 1: 
Introduction 


This chapter tells explains what DICOM 
is, why it was created, and what it is 
supposed to accomplish. 


Chapter 2: 
Basic OSI 
Concepts 


This chapter explains some basic and 
some not-so-basic OSI concepts with 
which you must be familiar to under- 
stand and apply DICOM to its fullest. 
Your understanding of these OSI 
concepts is important because OSI is the 
framework upon which much of 
DICOM is based. 


Chapter 3: 
Basic 
DICOM 
Concepts 


Like Chapter 2, this chapter covers 
some basic and some not-so-basic 
concepts. These are the building blocks 
of DICOM. 
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Chapter 4: 
DIGOM3.0 
Specification 
Navigator 


This is a guidebook/companion for the 
DICOM Specification document 

Its purpose is to make the huge spec 
document easier to read, understand, 
and apply by walking you through each 
part, section-by-section. 

The Navigator explains how to read and 
interpret information, how to find the 
information you're looking for, how 
different parts are interrelated, etc. 


Appendix A: 
DICOM3.0 
Specification 
Index 


This appendix contains an index for the 
DICOM 3.0 specification document. 
This is not the index for Understanding 
DICOM. 


Appendix B: 
Terminology 


This glossary contains two parts: 

• a glossary of important terminology 

• a list of acronyms and their defini- 
tions 


Appendix C: 
Understanding 
DICOM 
Index- 


This appendix contains the index for the 
Understanding DICOM book. 
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Chapter 2: Basic OSI Concepts 



Introduction 

DICOM 3.0 is based upon basic OSI concepts and you'll see many 
OSI terms occurring in DICOM. This chapter contains an explana- 
tion of the OSI concepts you must grasp before you can really under- 
stand DICOM. 



Application Entities 

An application entity ( AE) is simply an abstract term that represents 
an entity such as a printer, computer, software application, etc. These 
AEs exist in the 7th layer of the OSI protocol - the uppermost layer. 
For example, if your computer is sending information to a printer, 
your computer respresents one application entity and the printer 
represents another. 



Types of Communication 

Accomplishing communication between two AEs (like the computer 
and the printer described above) requires two types of communica- 
tion: 

• lateral communication between two entities at the same level 
(peer-to-peer) 

• vertical communication between layers (layer-to-layer). 

For communication to take place between two application entities, 
data must flow down through the layers below the first AE (layer-to- 
layer), across the wire connected the two AEs(peer-to-peer), and 
then up through the layers below the second AE(layer-to-layer). 

Therefore, an AE must perform layer-to-layer communication to 
achieve peer-to-peer communication. 
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Services and Protocols 



A "service" is what allows you to perform layer-to-layer communi- 
cation across a wire. It contains things like routines you would call 
to set up a transmission control protocol (TCP) socket. Elements of 
a service, like routines, are called "service elements" 

Things like the format the data must be in to perform peer-to-peer 
communication (e.g., to flow through the TCP socket successfully) 
are called "protocols:* 

Services Protocols 

♦ i 

are like application are like data 

interfaces formats 

and function and function 

layer-to-layer peer-to-peer 

In the world of OSI, protocols are defined exactly, and all implemen- 
tations must conform to those definitions. By contrast, services are 
abstract and only defined in a general sense (like the term "routine," 
etc.). 

Therfore, implementers may implement services in different ways, 
as long as they arrive at the correct protocol. The services are the 
same; their implementations of them are what's different. 

Your understanding of the differences between protocols and 
services is one of the most important steps in mastering the DICOM 
standard. This next few sections will help you gain this under- 



The Service Provider 

The sum of the layers below the application entities and the wire that 
connects the two sides is the "service provider" The service 
provider could be a combination of a network and all of the related 
network interface(s), etc. For example, when two AEs communicate, 
the service provider contains everything below each AE, including 
all of the service elements. The way services, protocols, and the 
service provider work together is this: 
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Say AE#1 wants to communicate with AE#2. To accomplish your 
goal, you must use services and protocols, and follow these basic 
steps: 

1. AE#1 becomes a "service user" because it uses services to 
"talk" to a service element inside the service provider. These 
services are what let AE#1 send its data down through the layers 
below it to that service element 

2. The service element on side #1 uses protocol to "talk" to its peer 
service element on side #2. The protocol dictates the format for 
the data. The service element on side #2, like the one on side #1 , 
is inside the service provider. 

3. The service element on side #2 uses services to "talk" to AE#2, 
telling it what AE#1 wanted to say. These services are what let 
the service element send data up through the layers below 
AE#2. 

If AE#2 wants to respond to AE#1, the process simply reverses. The 
following drawing illustrates this simple communication: 
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Service Parameters 

Each service has a set of corresponding parameters. These parame- 
ters are how you communicate information, ask that things be done, 
etc. (e.g, request an image, respond to a request, etc.). 

These parameters are passed to the service element inside messages. 
These messages correspond to the building blocks of OSI communi- 
cation known as the "OSI primitives." 

OSI Primitives 

In OSI, there are four basic communication "primitives:" 

• 1: request 

• 2: indication 

• 3: response 

• 4: confirmation. 

The way the service provider handles services involves the four OSI 
primitives. Take the same example that was used before in which 
AE#1 wants to communicate with AE#2. Now, however, we'll 
expand the level of detail to illustrate the involvement of the OSI 
primitives: 

1 . AE#1 wants to "talk" to AE#2, so it needs to use services to 
send data down through the layers below it and "talk" to a 
service element inside the service provider. To do this, AE#1 
uses the service parameters that match what it wants to do. It 
communicates these parameters to the service element inside a 
"request message." This request message is one of the OSI 
primitives. 

2. The service element on side # 1 uses protocol to "talk" to its peer 
service element on side #2. The protocol dictates the format for 
the data. The service element on side #2, like the one on side #1, 
is inside the service provider. 
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3. The service element on side #2 needs to use services to send 
data up through the layers below AE#2 so it can deliver the data 
from AE#1. To do this, the service element uses the service 
parameters that match what it wants to do. It communicates 
these parameters up through the layers to AE#2 inside an "indi- 
cation" message. This indication message is one of the OSI 
primitives. 

If AE#2 wants to respond to AE# 1 , the process simply reverses. This 
time, the remaining OSI primitives would be involved (response and 
confirmation). The following drawing illustrates this sample 
communication: 



















1: request 


•: 










2: indication 






Requesting 
Application 
Entity 

"AE 1 ^ 


(service) ^ 












(service) ™ 


Receiving 
Application 
Entity 

'AE" 




,4: confirmation 


I 


11 


. - ' 

network plus'". 


3: response 




1 r (service) 


| 


; :-;Cx : x : :-: : x" 




^ (service) 





2-6 



©1993 Kodak Health Imaging Systems. Inc. 



Chapter 2: Basic OSI Concepts 



Service Parameters in the Spec 

The DICOM 3.0 specification document contains tables that list the 
available parameters for each type of service. Within each of these 
tables are four columns that correspond to the four OSI primitives. 
For example, let's look at the following table from Part 8 of the 
DICOM 3.0 specification document: 



These four columns correspond to the OSI service primitives. 
(See the "OSI Primitives" section.) 



This column lists the parameters 
available for the service. r 

\ / 



A-ASSOCIATE Parameter Name 


Request 


Indication 


Response 


Confir- 
mation 


Application Context Name 


M 


M(=) 


M 


M(=) 


Calling AP Title 


M 


M(=) 


M 


M(=) 


Called APTiUe 


M 


M(=) 


M 


M(=) 


User Information 


M 


M(=) 


M 


M(=) 


Result 






M 


M(=) 


Result Source 








M 


Diagnostic 






V 


C(=) 


Calling Presentation Address 


M 


M(=) 






Called Presentation Address 


M 


M(=) 






Presentation Context Definition List 


M 


M(=) 






Presentation Context Def. List Result 






M 


M(=) 



From Part 8 of the Spec - Table 7.1.1-1 Key A-ASSOCIATE Service Parameters 



This is the table that lists the available parameters for the Key A- 
ASSOCIATE service. The spec document contains a chart like this 
for every available services. 
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As you can see, there are columns that correspond to each of the 
service primitives, and there are entries within those columns for the 
various parameters. 



if: •:,:,.„ 


then: 


a column is 
blank, 


that primitive doesn't apply for that param- 
eter. 

For example, the chart in the illustration 
shows that the "request" and "indication" 
don't apply for the Results parameter of 
that service. 


a column has an 
entry, 


that entry indicates things like whether that 
parameter is mandatory if you're using that 
primitive, conditional if you're using that 
primitive, etc. See the chart under "Types 
of Parameters." 



Types of Parameters 

The following chart explains the entries you'll see in the columns of 
the service parameter table: 



Indicator 


Meaning 


M 


Mandatory. 


U 


User option. 


c 


Conditional. (It is mandatory if a certain condi- 
tion is met) 


UF 


User option with a fixed value. If you use this 
option, you must use the fixed value. 


MF 


Mandatory with a fixed value. You must use this 
parameter, and you must use the fixed value. 


NU 


Not used. 
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Note: If there is an equal sign beside one of the indicators (=), it 
means one of the following things: 

• the indication must be identical to the request 

• the confirmation must be identical to the response. 



Your understanding of how to read these service parameter charts is 
important, because they tell you: 

• which parameters belong to a service 

• of those parameters, which ones are available for each of the four 
service primitives 

• for those service primitives, whether parameters are mandatory, 
conditional, optional, etc. 



Note: Not every service parameter appears in the protocol, be- 
cause some of the service parameters are merely used by 
the service provider to do things other than exchange infor- 
mation. See the example in the "Protocol Formats in the 
Spec" section of this chapter. 



©1993 Kodak Health Imaging Systems, Inc. 



2-9 



Understanding DICOM 3.0 



Protocol Formats 



As explained in the earlier example, the service element on side #1 
uses protocol to "talk" to its peer service element on side #2. This 
means that, to pass the appropriate service primitives (messages) 
across the link, service element #1 must "encode" the data, or put it 
into the format dictated by the protocol. 

The protocol is made up of the messages that correspond to the prim- 
itives. These messages are called "protocol data units" (pdu's). By 
and large, the pdu's have fields, and these fields contain the service 
parameters: 




protocol 



mm mffimw 



C<4 ~. 



'Receiving 

-•Hcattr- 
nffly 

.CAE #2) 



The service provider contains the four primitives, and the protocol 
contains the messages: 

The Service Provider: 
Contains the four primitives 






The Protocol: 
Composed of 
the messages 






I mm® I 
— > 






The Messages: 
Embodiment of 
the "primitives" 






^ 


1 ,($w*um. | 








2- 10 



©1993 Kodak Health Imaging Systems, Inc. 



Understanding DICOM 3.0 



Protocol Formats in the Spec 

Just like the specification document contains charts with parameters 
for the services, it also contains sections that describe the corre- 
sponding protocol formats. These protocol descriptions explain how 
the service elements must encode data to perform the various 
services. 

At first glance, there seems to be 1-to-l relationship between pdu 
fields and service parameters. However, the pdu's don't have to 
contain service parameters; they may also contain other things that 
relate to the reliable exchange of messages. The charts in the speci- 
fication document show you which parameters do and do not get put 
into pdu fields. 

For example, the "Service Parameters" section showed the service 
parameter table for the Key A-ASSOCIATE service, which you can 
find in section 7. 1. 1 of Part 8. Section 9.3.2 of Part 8 contains one of 
the tables that explains the "pdu structure," or specific protocol 
format, that applies to that service. The name of this pdu table is 
"Table 9.3.2.1-1: ASSOCIATE-RQ." (Refer to sections 7.1.1 and 
9.3.2 in Part 8 of the specification document.) 

On the following page are pictures of these two corresponding tables 
from Part 8 of the spec.The illustration contains arrows that show 
you where parameters from Table 7.1.1-1 are mapped to pdu fields 
in Table 9.3.2.1-1. 



Note: It is very important that you understand fully the differenc- 
es between the service parameters and the protocol formats 
when you see them in the spec. To get all the information 
you'll need for a service, you'll be doing a lot of flipping 
back and forth between sections that are related, like the 
ones in this example. 
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From Part 8 of the spec: Table 7.1.1-1 Key A-ASSOC1ATE Service Parameters 



A-ASSOCIATE Parameter Name 


Request 


Indication 


Response 


Confir- 
mation 


[Application Context Name 


M 


M(=) 


M 


M(») 


filing APTinj^ \^ 


M 


M(=) 


M 


M( e ) 




M 


M(«) 


M 


M(a) 


User Informatio^^^ 


\ — 


M(») 


M 


M(«) 


Result \N. X 






M 


M(-) 


Result Source 








M 


Diagnostic 






U 


C(=) 


Calling Presentation Address N^N. 










Called Presentation Address \/ 




M(») >w 






presentation Context Definition UsT^ 




M(=) 






Presentation Context Def. List Re\h 






M X 


M(«) 



PDU Bytes 



Field Name 



Description of Fie i 



PDU Type 



01H 



Reserved 



3.6 



PDU I 



This PDU Length 
the following field 



til be the numhsrbf bytes f 
to the last bytpW the variable f 



i as an unsigi ed 
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I Version 



Dbyteflelc shs 



This two 
COM UL protoco 
sion 1 and shall 
implementtns/xmr. 
test that WU> b se 



byi 

identified with t 
this version c 



ffng end-system. This b 
s^seL A receiver or this PdU 
t DltTOM UL protocol shal 



Reserved 



Tb>f reserved fleh 
lvalue when 



shaUfee sent with a value KKM)H but not tes id to 
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Called-Ap-tiUe 



Destination I 
ASCII chaj 



[ Application Name. It siall be encoded as 
ith leading and trailing i paces (20H) 



fit The * 
i Nairn 
h of the use of thb 



ue made oT 16 ASCII 
peciflecr shall not be 
field, see Section 7. 



snaps (20H) meaning 

.For a complete < sscrip- 
or this part 
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Calling-Ap-title 



Source DICOM A splication 
characters with le ding 



cant. The value 
tion Name spec! 
the use oT this fie! 



Name. It shall 
and trailing spaces 
mlde or 16 ASCII spaces 



* encoded as 16 / SCII 
2 OH) being non-si jnifl- 
(2lH) meaning "no/ ppiica- 



Name specified" shall not be used. For a complete description o 
, see Section 7.1.13 or th s part 



43-74 



Reserved 



This reserved fleh 
tested to this valu 



shall be sent with a vali ; 
when received. 



00H for all bytes but not 



A pplication 



75- 



Variable Items 



This variable nek shall contain the foil 
Context Item , dje or more, 
User Information Item. For a complete description of the use of 
these items see Sections 7.1.1 J, 7.1.L13, and 7.1.1.6 of this part. 



From Part 8 of the spec: Table 9.3.2-1 : ASSOCIATE-RQ PDU Fields 
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Notice that, in this example, not all parameters from Table 7.1.1-1 
are mapped to pdu fields in Table 9.3.2-1. For example, the "Calling 
Presentation Address" and "Called Presentation Address" parame- 
ters only appear in Table 7.1.1-1. Likewise, there are some pdu fields 
whose contents don't appear in the parameter table. These other 
pieces of information are important for the reliable exchange of 
messages (e.g, the port number of the entity you're calling, etc.). 

In this example, the "Result," "Result Source," "Diagnostic," and 
"Presentation Context Def. List Results" parameters also do not 
appear in the pdu table. Notice they are the only parameters that 
don't have entries in the "Request" and "Indication" columns. As 
explained before, an empty column means a parameter isn't avail- 
able for that primitive. 

The "RQ" stands for "request," and indicates that this pdu table 
applies to request/indication primitives. Therefore, this particular 
illustration shows the mapping of parameters for the Key A- ASSO- 
CIATE service request into an indication on the other side of 
communication. 



Note: Part 8 also contains pdu charts that correpond to the "re- 
sponse" and "confirmation" primitives (Tables 9.3.3-1 and 
9.3.4- 1). There are two tables, because one is for when a re- 
quest is accepted (ASSOCIATE-AC) and the other is for 
when a request is rejected (ASSOCIATE-RJ). 



In this same way, you can match up other parameter tables with their 
corresponding pdu tables. 
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Associations 

Earlier, we talked about how one side "talks" to another side. Now, 
let's talk about how they actually do it When two sides want to 
communicate, the first thing they must do is establish a context for 
communication. This context is called an "association" This asso- 
ciation provides the framework for communication in the DICOM 
world. 

Setting up an association, or "association negotiation" is basically 
the "handshaking" activity that takes place between the two sides. 
During this "handshaking," the two sides set boundaries as to what 
they do and do not support, thereby ensuring that neither attempts 
something the other doesn't support. Only those activities you have 
successfully negotiated are allowed to take place in an association. 
You can only use the presentation context that you negotiate. 

For example, say AE#2 is an archive that supports the storage of 
only one modalilty. Then, AE #1 sends a message saying "I want to 
send you images of several different modalities." Then, AE #2 
would respond with a message telling AE #1 which modalities it 
supports. Then, AE #1 would send only those images that belong to 
the supported modalities. 

The association makes sure that both sides are "talking the same 
language" and are trying to accomplish the same thing(s). For 
example, imagine that, during association negotiation, the following 
things take place: 

1 . Side #1 decides it wants to communicate certain things to side 
#2. These things could be information side #1 wants to pass 
along, activities it wants to make happen, etc. 

2. Side #1 "contacts" side #2 (using the services, protocols, etc., 
described previously), giving side #2 a sort of "list" of things it 
wants to do. ("I'd like to do these things.") 

3. Side #2 evaluates the things side #1 has requested and deter- 
mines which of those things it can actually do. ("Of the things 
you asked to do, these are the ones / can do, too.") 

4. Side #2 sends a response to side #1 (using services, protocols, 
etc.), giving it the list of things it can do. 
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5. Side #1 and side #2 can now "agree" which things they'll do, 
and there's no danger of one side trying to do something the 
other side doesn't support 

Association Control Service Elements 

The service element you use to set up an association is called an 
"association control service element," or "ACSE." According to 
OSI, an ACSE is part of layer 7, which is the application layer. It is 
an abstract type of thing and there are many ways of physically real- 
izing it 

It can be a device driver, a separate application to which you send 
messages, etc. In most cases, however, it is a library that you link 
with (a set of routines you call). In the C++ world, it is an object to 
which you send messages. 

In the world of ISO OSI, you use a standardized ISO definition of an 
ACSE. If you are running DICOM over an OSI stack, there is no 
need to have anything other than the standard ISO OSI definition of 
an ACSE. 



Note: The ACSE is what you use to establish the association. Af- 
ter you've established it, you will then use the DICOM 
Message Service Elements, or "DIMSEs" to transfer your 
messages back and forth. See the section of Chapter 3 enti- 
tled "Dicom Message Service Elements." 



Part 8 of the specification document is an ACSE definition that is 
divided into three different sections: 

• Section 7 of Part 8 is a service definition 

• Section 8 of Part 8 is the OSI profile that defines the ACSE 
protocol using OSI 

• Section 9 of Part 8 is the upper layer protocol for TCP/IP. (The 
OSI protocol is defined in the OSI specs). Both OSI and TCP/IP 
protocols use the same service definition, because an ACSE 
provides the same service for both. 
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Setting up an Association 

To set up an association, you need the following things: 

• a transport connection 

• the requesting AE title 

• the receiving AE title 

• an application context 

• a set of presentation contexts. 

Transport Connection 

A transport connection is basically a way of moving unstructured 
data across the network (e.g., TCP/DP socket or stream). It is a pipe- 
line; you dump data in one end and it comes out the other end and 
vice versa. 



Requesting AE Title 

The requesting AE title is the name of the application entity (AE) 
that is initiating the communication. 

Receiving AE Title 

The receiving AE title is the name of the application entity ( AE) that 
is receiving the communication. 

Application Context 

Associated with a transport connection is an application context. 
There is only one application context that is used for all DICOM 
communication, and that is DICOM 3.0. 



Presentation Context 

A presentation contains the transfer and abstract contexts. See the 
"Presentation Contexts" section of Chapter 3 for a detailed explana- 
tion. 
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Here's how you go about establishing an association: 



1. Application Entity #1 invokes the A-ASSOCIATE request 
service. (Sends a request to ACSE #1) 



Slde#1 




request 



Side #2 



The way you do this depends upon the language you're using: 



If you're using: 


then: 


something other than C++ 


you call the associated 
request routine. 


C++ 


you send the A-ASSOCIATE 
request message to the ACSE 
object 



As described earlier, each service has a set of corresponding pa- 
rameters. If you look in the spec at section 7.1.1 of Part 8, you'll 
see the chart that contains the parameters for the A-ASSOCI- 
ATE request service. 

Notice that two of the mandatory parameters for this service are: 

the Called Presentation Address, which is the TCP host 
name and port number with which you want to connect 

• the Calling Presentation Address, which is your own host 
name and port number. 
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Note: The earlier example that mapped a parameter table to a pdu 
table showed that these two parameters are not put into 
pdu's. 



In step 1, you're sending the A-ASSOCIATE request and its pa- 
rameters to the ACSE. 

2. The ACSE for Side #1 uses the Called Presentation Address to 
establish a transport connection (TCP/IP socket) between side 
#1 (you) and side #2 (the entity with whom you want to 
connect). 

3. ACSE #1 builds a message that explains what the request 
"wants." (The spec contains protocol descriptions that describe 
what these messages should look like. Refer to the earlier 
section in this chapter entitled "Protocols and Services" for 
more details.) 

4. ACSE #1 sends the request message to side #2. 



Side #1 



Side #2 



AE#1 



request 
message 





5. 



The ACSE for Side #2 "sees" the message. 
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6. The ACSE #2 decodes the message and sends the indication to 
Application Entity #2. 



Side #1 




ACSE #1 



Side #2 



indication 







ACSE 


#2 



7. AE #2 processes the indication and then generates a response. 
AE #2 sends the response to ASCE #2. 



Side #1 




ACSE #1 



Side #2 



response 




8. ASCE #2 builds a message that explains the response. 
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9. ACSE #2 sends the response message back across to Side #1 . 



Side #1 




Side #2 



response 
message 



mmm 



10. ASCE #1 "sees" the message. 

1 1. ASCE #1 decodes the message and sends the confirmation to 
AE#1. 



Side #1 




Side #2 



confirmation 



Once AE #1 has received the confirmation, it means you have 
successfully negotiated the association. 

The content of the messages allows you to specify everything about 
that association. It allows you to: 

• list the presentation contexts 

• list all of the options associated with all of the abstract syntaxes 
(SOP class; see Chapter 3) 

• establish an application context (DICOM 3.0). 
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Introduction 

If you're going to become comfortable with the new DICOM stan- 
dard, you must master the following information: 

• Basic OSI concepts 

• Basic DICOM concepts. 

These two areas of information represent the foundation upon which 
DICOM is built. Chapter 2 of this book describes the basic OSI 
concepts, and this chapter explains the basics of DICOM. 



Information Objects 

DICOM is sort of object-oriented, in that it defines an information 
model that lets you describe information in a standardized way 
through the use of information objects. Instead of talking about 
performing operations on images that have headers, you talk about 
performing operations on information objects that have attributes. 

When you use these common, standardized terms for communica- 
tion, you are able to overcome the limitations of working with 
multiple platforms, multiple vendors, etc. 

Information objects are more explicit than terms you might have 
used before. For example, you might have used the same word - 
"image" - to describe any of a number of different types or "modal- 
ities" of images (e.g., CTs, MRs, etc.). However, there is nothing 
inherent in the term "image" that tells you what type of image you're 
dealing with. 

In DICOM, you no longer use a term as vague as simply "image." 
Instead, there are explicit information objects that correspond to 
each type of image. So, if you're describing a CT image, you use the 
information object that means "CT image." In this same way, there 
are explicit information objects for patients, studies, results, etc. 
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Information Object Definitions 

The DICOM 3.0 contains descriptions of the information objects. 
These descriptions are called "information object definitions," or 
"IODs." This is a term you'll hear often, and it is basically inter- 
changeable with "information object" 

Attributes and Values 

Each type of information object has its own set of characteristics or 
attributes. In turn, each attribute can have its own value. These 
attributes and their corresponding values are how you differentiate 
between multiple items of the same information object type (e.g., 
multiple CTs, multiple MRs, etc.). 

All information objects of a certain type have the same set of 
attributes; it's their values that make them unique. 



Note: Not all attributes are required to have values every time. 
See the "Types of Attributes" section. 



Information objects and their attributes work together in the same 
logical way you'd describe just about anything. For example, say the 
term "human being" is a type of information object. All members of 
that object type (human beings) have certain attributes, such as their 
sex, name, height, age, etc. 
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What makes each person unique is the values they have for those 
common attributes, as shown below: 



iniwii iivniwi ■ uujovi : 


rift ri Hi ft a < 


values 


(general type) 


(characteristics 


(details of a 


of the type) 


specific 




instance) 


human being 


sex 


male 




first name 


Bob ! 




last name 


Smith 




height 


5'ir 




hair color 


brown hair 




shoe size 


12 




age 


43 years 


human being 


sex 


female 




first name 


Jane 




last name 


Doe 




height 


5'6" 




hair color 


red hair 




shoe size 


8 




age 


32 years 
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Types of Attributes 



Information object attributes fall into three categories: 



Type of Attribute 


Description 


required 


To be valid, an information 
object must always contain a 
value for this attribute. 


conditional 


If a certain condition is met, 
this becomes a required 
attribute and the information 
object must contain a value 
for it. 

If the condition is not met, 

Ullo OlulUUlC UvCUIlICo 

optional and the information 
object may or may not 
contain a value for it. 


optional 


This attribute is not required. 
The information object may 
or may not contain a value 
for it. 
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Modules 

The attributes for information objects are grouped together into 
logical units called modules. These modules represent groups of 
attributes that belong together because of the type of information 
they describe, they depend upon each other, etc. For every informa- 
tion object, there is a corresponding set of modules. These modules, 
in turn, contain the attributes that are valid for the information 
object 



Modules in the Spec 

Chapter 2 explained how the specification document contains tables 
and sections that describe the parameters and protocols for the 
various services. In this same way, the spec document also contains 
sections that describe the modules that belong to information 
objects, and the attributes that belong to those modules. 

To find the attributes for a particular information object, first you 
locate that object's module table in either Annex A or Annex B of 
Part 3 (depending upon whether you're dealing with a normalized or 
composite object). That module table will list the modules that are 
available for the information object. 

Then, you locate the individual module tables that belong to each of 
the modules in the list. These individual module tables list the 
attributes available for each module and, therefore, for the informa- 
tion object. 
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For example: 

IOD module tables are in: 

• Annex A of Part 3 for composite objects 

• Annex B of Part 3 for normalized objects. 

Individual module tables are in Annex C of fcirt 3. 



Individual Module 
Table "A" 



Lists attributes of 
the module "A" 



Module Table for an IOD 




Lists applicable modules/ 




for an IOD: 7 




Module 'A' 'y^ 




Module 'B' ' 




Module 'O ^ 




Module^' 





Individual Module 
Table-B- 



usts attributes of 
the module 'B' 



Individual Module 
Table "C 



Lists attributes of 
the module 'C 



Individual Module 
Table "D" 



Lists attributes of 
the module 'D' 
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Here's a specific example from the spec: 



For example, section A.4.3 of Part 3 contains the 
Module table for the MR Object IOD. One of 
the individual modules it lists is 'Image Plane.' 

Section C.7.6.2 contains the Image Plane 
Module Table. This table lists the attributes 
for the Image Plane Module. 



Module Table for 
MR Image IOD 



Module Table for 
Image Plane Module 



Lists applicable modules 
for the IOD, including: 




Lists attributes of 
the module. 



Image Plane Module 



©1993 Kodak Health Imaging Systems. Inc. 



3-7 



Understanding DICOM 3.0 



Types of Information Objects 

There are two types of information objects which represent two 
different ways of looking at information. They are closely-related, 
yet different information models. 



The following types of information objects exist: 



Type of Information 
Object 


Description 


composite 


Composite objects, which 
contain the attributes of 
many real-world objects. 

They are consistent with the 
way ACR-NEMA 2.0 
worked. 


normalized 


Normalized objects, which 
contain the attributes of only 
one real-world object. 



The main difference between the two types of objects is in the way 
that you use them. The way you use them depends upon how closely 
coupled the systems doing die communicating are. 



For example, say a modality is sending images to a picture archiving 
and communications (PACS) system, which is going to store the 
images. The details of how the PACS system accomplishes this don't 
have to matter to the modality; the modality just wants the PACS to 
do its job. Therefore, the modality can just put all of its image and 
demographic data into one neat package or composite object, and 
"tell" the PACS to store it. 

By contrast, however, say the modality wants to print an image on a 
printer. The way the printer handles the information is very impor- 
tant to the modality, because it affects the way the image is tones- 
caled, formatted, etc. The modality can control these things by using 
normalized objects such as film sessions, film boxes, images boxes, 
etc. 
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Pointers 

Because the attributes for normalized objects are split up so they're 
not shared by more than one object, you must link together several 
objects to get all of the attributes you want. You can do this by using 
pointers. 

For example, the header of a composite information object might 
contain, in addition to demographic data, pointers to all of the appli- 
cable normalized objects, thus tying the correct images to the correct 
demographic data. These pointers take the form of unique identifiers 
(UIDs) that belong to each object. (See "Unique Identifiers.") 

Information Object Identifiers (UIDs) 

DICOM 3.0 provides a technique for assigning a unique identifier to 
every information object. This technique is based upon the OSI 
naming procedures, and it allows you to generate what are guaran- 
teed to be globally-unique character strings. These unique identi- 
fiers, called "UIDs," are how you reference information objects 
inside headers. 

These UIDs serve as the pointers described above. 
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Service Classes 

As explained previously, DICOM provides a way to describe the 
items upon which you want to perform operations (information 
objects and their attributes). Likewise, DICOM also provides a way 
to describe those operations you want to perform - service classes. 
In ACR-NEMA 2.0, you selected a set of elements that applied for 
your applications. In DICOM, you select the service class that 
matches what you want to do. 

Existing Service Classes 



The following service classes already exist 



Service Class 


Use 


Verification 


To perform ECHO commands. 


Storage 


To perform SEND commands. 


Query/Retrieve 


To list images on a device and then 
either retrieve or send. 


Print Management 


To manipulate printers. 


Patient 


To track the status of patients. 


Study 


To track the status of studies. 


Results 


To track the status of results. 



Part 4 of the spec describes service classes. It is composed of a body 
of descriptive text, plus several appendices or "annexes." The body 
contains a general description of service classes and their character- 
istics. Each annex explains one of the existing service classes in 
detail, including a description of its operations at the application 
level (using DICOM). See the "Spec Handbook." 
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Service/Object Pairs 

The previous sections described information objects and service 
classes. The next concept is the combination of the two - service/ 
object pairs. A service/object pair (SOP) is a combination of the 
service class and the type of information object upon which it should 
operate. 

It is a generic term, in that it refers to an action taken with a type of 
information object, rather than a specific information object (e.g., 
"store a CT," as opposed to "store Jane Smith's CT). 



Note: For those of you who are familiar with object-oriented 
analysis, a SOP in DICOM corresponds to an object in the 
object-oriented sense. 



Service/Object Pair Instance 

A Service / Object Pair instance takes it one step further, from the 
generic SOP class to a specific occurrence or instance of an infor- 
mation object (e.g., "store Jane Smith's CT'). 



Application Contexts 

DICOM makes use of transport connections, which are simply ways 
of moving unstructured data across a network (e.g., TCP/IP socket 
or stream). Built on top of the transport connection is a association. 
(See "Associations.") 

This association has an application context, which, for all DICOM 
communications, is DICOM 3.0. 



Note: The association also has a set of presentation contexts, 
which are described in the next section. 
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Presentation Contexts 

As described in Chapter 2, you must put data into a specific format 
(protocol) to send it back and forth across a communications pipe- 
line. Encoding data into the correct protocol on one side of the 
communication ensures that it can be decoded accurately on the 
other side. In DICOM, you use presentation contexts to do this 
encoding and decoding. 

The purpose of presentation context is to make sure that both sides 
agree: 

• what they're going to be doing 

• how they're encoding the data. 

The way a presentation context makes sure of these things is through 
its two components: 

• transfer syntax 

• abstract syntax. 

Transfer Syntax 

A transfer syntax indicates how the operation and the information 
objects should be encoded (e.g., "big Endian," "little Endian," 
"compressed," etc.). 

Abstract Syntax 

An abstract syntax is the same as the SOP (service/object pair) class. 
As described previously, the SOP class is a combination of a service 
class and a type of information object. This means the abstract 
syntax for a presentation context should contain these two things: 

• the service class to which the presentation context belongs 
(e.g., storage) 

• the type of object upon which the presentation context should 
operate (e.g., CT, MR, etc.) 
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When you perform an operation, thus sending a packet of informa- 
tion, you send it within the scope of a presentation context. You use 
the presentation context to encode the data at the sending end and 
then to decode the information at the receiving end, and vice versa. 

Because it's the SOP class that describes the kind of operation you 
want to perform, that is where the presentation contexts fit into the 
big picture. There are presentation contexts that correspond to the 
activities that belong to SOP classes. 

For example, the "Storage" service class contains SOP classes for all 
of the following activities: 

• sending/storing CT objects 

• sending/storing MR objects 

• sending/storing x-ray objects. 

All of these activities belong to the Storage service class, but they all 
represent a different presentation of an object. Therefore, they each 
have their own presentation contexts. 



Note: Each abstract syntax has its own unique ID (UID), which 
matches the UID of the corresponding SOP class.(An ab- 
stract syntax is the same thing as a SOP class.) 

Each presentation context has its own ID, called a "presen- 
tation /D." Whenever you send a packet of data, you send 
the ID of the corresponding presentation context. 

A presentation I.D. applies to the current association only. 
(See "Associations" in Chapter 2.) Two different associa- 
tions may have identical presentation IDs, but those IDs 
don't necessarily mean the same thing. 



Abstract Syntax Options 

An abstract syntax may also have a set of options. These options 
apply to the abstract syntax, wherever that syntax may occur. There- 
fore, because these options are associated with the abstract syntax 
and not the presentation context, it is possible to have two different 
presentation contexts that use the same abstract syntax. 
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For example, you can have one presentation context that is for the 
storing of CTs using a "big Endian" transfer syntax. The abstract 
syntax for this context would indicate that it uses the Storage service 
class, and that it operates upon CTs. 

You could also have another presentation context that is for the 
storing of CTs using "little Endian" transfer syntax. This presenta- 
tion context also uses the Storage service class and operates upon 
CTs. The difference between these two examples is their transfer 
syntax (big Endian vs. little Endian), not their abstract syntaxes. 



Note: As indicated before, an abstract syntax is the same as a SOP 
class. The options described above are actually SOP class 
options, which you can find in the annexes of Part 4 of the 
spec. They're the items discussed under "Extended Nego- 
tiations." 
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DICOM Message 
Service Elements 

Chapter 2 explains what service elements are. It also explains that, 
when you set up an association, the service element you use is the 
association service control element, or " ACSE." However, after you 
set up an association, you use a different type of service element to 
transfer your messages back and forth. This type of service element 
is the DICOM Message Service Element, or "DIMSE." 

DIMSEs are somewhat patterned after the following sets of OSI 
protocols: 

• CMIS (Common Management Information Service) 

• CMIP (Common Management Information Protocol). 

The whole idea is to isolate functionality into these DIMSE service 
elements up in the application layer. The DIMSE service elements 
represent a common set of services that you use over and over. 

As an implemented you can distribute your functionality into service 
elements throughout you application however you want to. DIMSE 
is simply an abstraction of a common set of things that you do in 
different contexts. 



©1993 Kodak Health Imaging Systems. Inc. 



3-15 



Understanding DICOM 3.0 

Like all service elements, DIMSEs are inside the service provider. 



DIMSE#1 



Side#1 



Side #2 




DIMSE #2 



The "DIMSE Service Provider" is 
everything below the solid gray line. 



Types of DIMSEs 



As described earlier, DICOM uses both composite and normalized 
information objects. Part 7 of the specification document contains 
DIMSEs that correspond to these types of objects: 

• DEMSE-C is for composite 

• DIMSE-N is for normalized. 
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DIMSE-C 

Section 9 of Part 7 describes DIMSE-C and its available services, 
which correspond to the old ACR-NEMA commands that operate on 
images: 

• STORE (formerly SEND) 

• FIND 

• GET 

• MOVE 

• CANCEL 

• ECHO. 

Section 9 contains the following information for each DIMSE-C 
service: 

• service specification (which describes the service) 

• sequencing specification (which describes the sequence for the 
messages) 

• protocol specification (which describes the protocol you should 
use for the service. 

To get all of the information you need about these services, you must 
flip back and forth between these related sub-sections. 

DIMSE-N 

Section 10 of Part 7 describes DIMSE-N and its available services. 
These services are very similar to and are based upon the CMIS 
services for remotely operating on objects: 

• N-CREATE 

• N-SET 

• N-GET 

• N-DELETE 

• N-ACTION 

• N-EVENT. 
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Like section 9 for DIMSE-C services, section 10 contains the 
following information for each DIMSE-N service: 

• service specification (which describes the service) 

• sequencing specification (which describes the sequence for the 
messages) 

• protocol specification (which describes the protocol you should 
use for the service. 

To get all of the information you need about these services, you must 
flip back and forth between these related sub-sections. 
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Introduction 



This chapter walks you through each part of the DICOM 3.0 speci- 
fication document, giving you a thumbnail description of each part 
and its sections. It also points out important areas and interrelation- 
ships between sections. 

The part and section numbers are separated by a forward slash (J) as 
shown below: 



part numbers 



1/ 

3/ 
5/6, 



0.1 

C.7.5.1.1.1 
.1.2.2 



1/ 

3/ 



5/6. 



0.1 

C.7.5.1.1.11 
.1.2.2 



section numbers 



For example, you'd read these examples like this: 
•section 0.1 of Parti ' 

•section C.7.5.1.1.1 (in Appendix C) of Part 3" 
•section 6.1.2.2 or Part 5 r 



Note: This navigator "hits the highlights" of each section and any 
important sub-sections. It doesn't address every single sec- 
tion. 
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Quick Reference 



Here's a quick reference chart to help you find sections inside the 
Navigator: 



This part: 


talks about: 


and starts on 
page: 


1 


Basic introductory and 
historical information: 

• normative references 

• goals of the standard 

• definitions, etc. 


4-5 




Conformance: 




2 


• what it means to conform to the 
standard 

• what the purpose of a conform- 
ance statement is 

• what a conformance statement 
looks like, etc. 


4-7 




Information object definitions: 




3 


• definitions, both normalized 
and composite 

• DICOM information model, 

• module tables 

• coding scheme designators 

• explanation of patient orienta- 
tion, 

• index to attribute tags, etc. 


4-9 
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4 


Service class specifications: 

• definitions 

• oescnpiion ox service classes 

• description of association nego- 
tiation 

• SOP class definitions 

• association negotiations, etc. 


4-14 


5 


Data structure and semantics: 

• data structure and encoding 

• value encoding 

• value representation 

• nesting of datasets 

• retired elements 

• encoding pixel data 

• transfer syntax specs 

• character repertoire, etc. 


4-24 


6 


Data dictionary: 

• rpoicfTv of iminnp idpntifipr^ 

IvgluUY KJL UluUUv AVAv/llUl-AV/JlO 

• value representations 

• attribute tags (group/element 
numbers) 

• value multiplicity, etc. 


4-29 
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Message exchange: 




7 


• message structure 

• command set 

• DIMSE services (-C and -N) 

• service specifications 

• sequencing specifications 

• protocol specifications 

• application context usage 

• data element cross-referencing 

• status type encoding 

• association negotiation 

• command dictionary 

• index for application context 
name UIDs, etc. 


4-30 




Network communication 
support for message exchange: 




8 


• communications support envi- 
ronment 

• OSI upper layer service 

• OST nnnpr 1flv**r nrnfilp 

• TCP/IP upper layer protocol 

• application context names 

• abstract/transfer syntax names 

• DICOM addressing, etc. 


4-34 


9 


Point-to-point communication 

ciinnort for itipccaop PYrhancrp 

(forward compatibility). 


4-37 


10 


Media storage and file format 

(file formats for when a dataset is a 
file). 


4-38 
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Part 1 : Introduction 
and Overview 



Note: Part 1 was approved before the other parts were finished, so 
some sections may not reflect the relationships between 
parts of the specs the way they really turned out (e.g., sec- 
tion 6.5 doesn't really reflect part 5 accurately). 



1/0 



VI 



1/2 



1/3 



1/4 



Introduction 

This section gives a concise description of ACR-NEMA and the 
ACR-NEMA standard. It provides a brief history and outlines some 
of the goals of the standard. 



Scope and Field of Application 

This section gives a concise statement of what DICOM 3.0 does and 
doesn't do. 



Normative References 

This section contains normative references. 

Definitions 

This section contains definitions of terms used throughout the stan- 
dard. 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 
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1/5 

Goals of the DICOM Standard 

This section is self-explanatory. 

1/6 

Overview of the Content of the DICOM Standard 

This section is self-explanatory. 

1/7 

Relationships of Paris of the Standard 

This section is self-explanatory. 
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Part 2: Conformance 

This part of the specification addresses conformance. It would be a 
good idea for you to read this part of the spec early on in your study 
of the spec, because understanding what "conformance" to the spec 
means is integral to understanding the standard itself. 

This section is particularly important if you are an implemented 
because you'll have to select and indicate the parts of the standard to 
which you're going to conform. Studying the information in this part 
will give you some idea of how you go about doing that 

2/1 

Scope and Field of Application 

This section tells what Part 2 does and doesn't specify. What this 
part doesn't specify is basically testing and verification procedures 
for the options you select. 

2/2 

Normative References 

This section contains normative references. 

2/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 



2/3.10 - DICOM Conformance 

This is an important section, because it contains definitions that 
specifically relate to conformance. It defines the ways you can 
choose to conform to the standard. 

2/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 
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2/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in Annexes A and B of Part 2. 

2/6 

Purpose of a Conformance Statement 

This section is self-explanatory. 

2/7 

Conformance Requirements 

This section explains what you have to do to conform to the stan- 
dard. The latter part of this section explains how to use the informa- 
tion that was described in section 2/3.10. 

2/A 

DICOM Conformance Statement Template 

This section provides a sample statement you can use to write your 
own conformance statement. 

If you're implementing DICOM, this is something you should study 
very early in your design phase. You can plan for conformance by 
trying to describe your application and how you're using DICOM 
according to this conformance statement 



Note: When you look at the template, you'll see that some of the 
numbers for its sections contain x's. These numbers corre- 
spond to sections you may have to repeat several times in 
your own conformance statement; the x's are variables you 
should increment as you number your own sections. 



2/B 

Sample Conformance Statement 

This section contains a sample conformance statement for an imag- 
inary application. It is filled out according to the template in 
Appendix 2/A. 
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Part 3: Information 
Object Definitions 

3/1 

Scope and Field of Application 

This section tells what Part 3 does and doesn't specify. 

3/2 

Normative References 

This section contains normative references. 

3/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 

3/3.8 - DICOM Information Object Definitions 

This section describes a number of things that are used to describe 
DICOM information objects. (See "Information Objects" in Chapter 
3.) 

3/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 

3/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in the Annexes. 
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3/6 

DICOM Information Model 

This section represents one of the real keys to understanding what 
the spec is all about You should study sections 3/6 and 3/7 together, 
along with parts 4/6 and 4/7, because they lay the philosophical 
groundwork for using DICOM. 

This section (3/6) describes the DICOM information model. It 
explains what IODs are, what service groups are, and how they're 
combined to make service and SOP classes. (See "Service Classes" 
and "Service/Object Pairs" in Chapter 3.) 

3/7 

DICOM Model of the Real-World 

In describing the DICOM model of the real-world, this section 
includes the things that the standard is supposed to deal with, like 
patients, images, studies, reports, and all of the other things neces- 
sary to handle medical images. There are two perspectives: what's 
really there in the real world, versus the things that are actually 
considered relevant for medical communications and are modeled in 
the standard. 

3/A 

Composite Information Object Definitions 

This appendix defines the attributes of the composite information 
object definitions (IODs). These attributes are discussed in terms of 
collections of attributes, which are modules. Appendix 3/C describes 
these modules. 

This means that, if you are trying to find out which attributes actually 
belong to an information object, you must literally flip back and 
forth between attribute definitions in this appendix and the corre- 
sponding module definitions in Appendix 3/C. This procedure of 
moving back and forth between annexes is illustrated in the 
"Modules" section of Chapter 3. 

3/A.l - Elements of an Information Object Definition 

This section describes what the composite IODs will look like. 
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3/A.1.2 - IOD Entity-Relationship Model 

This section contains an entity-relationship model. A 
composite IOD is made up of several real-world entities, 
one or more of which might go into an information object 
This model that illustrates the relationship between entities 
that correspond to real-world things (e.g., patients, studies, 
equipment, images, etc.). 

3/A.1.3-IOD Module Table 

This section describes what a module table is. This is 
important information for understanding how to implement 
DICOM. 

3/A.1 A - Overview of the Composite IOD 
Module Content 

This section contains a table that shows which modules go 
into which IODs. It's a very handy reference to keep 
around; a tabular format that shows how appendix A corre- 
sponds to appendix C. 

3/A2 - A13 - Information Object Definitions 

These sections contain information object definitions (IODs). 

3/A.2.3 
3/A.3.3 
3/A.4.3, etc. 

Image IOD Module Table 

These sections contain the module tables for their respec- 
tive information object descriptions (from sections 3/A2 - 
A 13). Each module table points you to all of the modules 
for the information object. (The modules themselves are 
described in appendix 3/C). 

The module tables also tell you which modules are 
optional, conditional, etc. They break the modules down 
according to the information entities like the ones 
described in the entity-relationship model in section 3/A1. 
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Note: Sections 3/A2 - 3/A13 all contain information object defi- 
nitions and their module tables, and are all in the same for- 
mat. 



3/B 

Normalized Information Object Definitions 

This appendix contains the normalized information object defini- 
tions. These definitions are broken into two parts: 

• the description of the IOD (what it's all about) 

• the module table. 

The module tables in this appendix are just like those for the 
composite IODs in appendix 3/A, only simpler. Normalized infor- 
mation objects don't have the additional layer of "information enti- 
ties." As with the composite objects, the modules themselves are 
described in Appendix 3/C. 



Note: There is a common question that arises in reference to the 
information in appendices 3/A and 3/B: Why do composite 
tables in appendix 3/A define usage for the various at- 
tributes, while the normalized tables in 3/B do not? 

This is because, for normalized objects, usage of their at- 
tributes depends upon the DIMSE service you're using. 
The only usage for composite objects is the storage of im- 
ages, so their usage can be defined. 



3/C 

Information Module Definitions 

This appendix contains the definitions for the modules alluded to in 
appendices 3/A and 3/B. This is the location of a large part of the 
details in the specification. 

The modules are grouped within a hierarchy according to the infor- 
mation objects in which they're used. For example, 3/C.2 contains 
patient-related modules, 3/C.3 contains visit related modules, etc.. 
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Annex 3/C is where you can find all of the detailed semantics for the 
attributes in the standard, so if you want to know what a particular 
data element means, this is where you look. Annex 3/F can help you, 
too, because it's an index for Part 3, where you can look things up 
according to their attribute tag (the old, ACR-NEMA 2.0 group/ 
element number). 



Note: You'll see that some of the module tables have a "type" col- 
umn and some do not If a table has a "type" column, it ap- 
plies to composite and normalized objects. If there is no 
"type" column, it applies to normalized objects only. 



3/D 

Coding Scheme Designators 

This annex defines coding schemes you could use to encode 
attributes. Its a reference section that is related to the detailed seman- 
tics of what goes into the attributes themselves. 

3/E 

Explanation of Patient Orientation 

This annex was not present in the review draft of the specification. 
It contains illustrations that appeared in the ACR-NEMA 2.0 spec 
document The illustrations explain concepts of patient orientation, 
like relating anterior to posterior, etc. 

3/F 

Index to Attribute Tags 

This is an index for Part 3. It lets you can look things up according 
to their attribute tag, which is the old, ACR-NEMA 2.0 group/ 
element number. 



©1993 Kodak Health Imaging Systems, Inc. 



4-13 



Understanding DICOM 3.0 



Part 4: Service Class 
Specifications 

4/1 

Scope and Field of Application 

This section tells what Part 4 does and doesn't specify. 

4/2 

Normative References 

This section contains normative references. 

4/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 

4/3.8 - DICOM Service Class Definitions 

This section describes a number of things that are used to describe 
DICOM service classes. (See "Service Classes" in Chapter 3.) 

4/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 

4/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in the Annexes. 
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4/6 

DICOM Information Model 

This section represents one of the real keys to understanding what 
the spec is all about You should study sections 3/6 and 3/7 together, 
along with parts 4/6 and 4/7, because they lay the philosophical 
groundwork for using DICOM. 

This section (4/6) describes the DICOM information model. It 
explains what IODs are, what service groups are, and how they're 
combined to make service and SOP classes. (See "Service Classes" 
and "Service/Object Pairs" in Chapter 3.) 

4/7 

DICOM Model of the Real-World 

In describing the DICOM model of the real-world, this section 
includes the things that the standard is supposed to deal with, like 
patients, images, studies, reports, and all of the other things neces- 
sary to handle medical images. There are two perspectives: what's 
really there in the real world, versus the things that are actually 
considered relevant for medical communications and are modeled in 
the standard. 

4/A 

Verification Service Class 

This appendix describes the verification service class, which is just 
about the simplest service class. It is the only one that doesn't have 
an information object associated with it; all it does is verify commu- 
nications through using the "echo" command. 

4/B 

Storage Service Class 

This appendix describes the storage service class, which is for the 
operation of sending an image from one AE to another. 

4/B.l - Scope 

This section describes the scope of the appendix. 
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4/B.2 - Behavior 

This section describes the behavior of this service class for a service 
class user (SCU) and a service class provider (SCP). It includes 
status messages that can be returned for various conditions. 

4/B.3 - Association Negotiation 

This section describes association negotiation for this service class, 
which is the "hand-shaking** you must perform to set up an associa- 
tion between two AEs who want to use this service class. Refer to 
the corresponding sections in Parts 7 and 8 for additional informa- 
tion. 

4/B.3.1 - Extended Negotiation 

This section describes extended negotiation, which is a part 
of association negotiation that is unique to the storage 
service class. To fully understand this information, refer to 
the "Association Negotiation" sections in Parts 7 and 8 
first. 

4/B.4 - Conformance 

This section tells you what you have to do to conform to the storage 
service class. It is divided a section for a service class provider 
(SCP) and service class user (SCP) Once you've picked a service 
class you want to use, you must decide whether you want to be a user 
or a provider. (You can be both but you must satisfy the conformance 
requirements of both.) 

4/B.4.1 - Conformance as an SCP 

This section describes conformance as a service class 
provider (SCP). 

4/B.4.2 - Conformance as an SCU 

This section describes conformance as a service class user 
(SCP). 

4/B.4.3 - Conformance Statement Requirements 

This section explains the conformance statement require- 
ments. Like in the previous sections this information is 
broken down according to SCP and CSU. 
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4/B.4.4 - Specialized Conformance 

This section tells you what you have to do if you want to 
enhance or extend the storage service class. 

4/B.5 - Standard SOP Classes 

This section is a list of the standard SOP (service/object pair) classes 
and their UIDs. These correspond to the abstract syntax UIDs you 
must use in association negotiation. 

4/C 

Query/Retrieve Service Class 

This section describes the query/retrieve service class. This is an 
unusual service class, because instead of IODs, it has query/retrieve 
information models associated with it This annex defines these 
models. 

The overall structure of this annex is this: 

• sections 4/C1 - 4/C5 describe the framework of a SOP class of the 
Query/Retrieve service class. 

• C6 describes the actual SOP classes of the Query/Retrieve service 
class, building upon that framework. These SOP classes contain 
an entity-relationship model. 

4/C.l - Scope and Field of Application 

This scope and field of application contains some valuable informa- 
tion about this service class; you should read it carefully. 

4/C2 - Query/Retrieve information Model Definition 

This section provides a general description of a query/retrieve infor- 
mation model (e.g., contains the SOP class of the service class that 
corresponds to the information model). This section tells you what 
goes into the model and how they're defined. 

4/C3 - Standard Query/Retrieve Information Models 

This section provides a sort of "preview" of the different informa- 
tion models that will be described later in 4/C.6, without actually 
defining them. 
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4/C.4 - DIMSE-C Service Groups 

This section describes the services that are used with all of the infor- 
mation models (e.g., find, move, get, etc., - defined in detail). 

4/C5 - Association Negotiation 

This section describes extended negotiation, which is a part of asso- 
ciation negotiation that is unique to the storage service class. To fully 
understand this information, refer to the "Association Negotiation" 
sections in Parts 7 and 8 first. 

4/C6 - SOP Class Definitions 

This section contains descriptions of three query/retrieve informa- 
tion models: 

4/C.6.1 - Patient Root SOP Class Group 

This section describes one of the query/retrieve informa- 
tion models. There are three SOP classes associated with 
this model, and they correspond to the operations you're 
allowed to perform (find, move, and get). Section 4/C.6. 1.3 
defines these SOP classes and their UIDs. 

4/C.6.2 - Study Root SOP Class Group 

This section describes another of the query/retrieve infor- 
mation models. There are three SOP classes associated 
with this model, and they correspond to the operations 
you're allowed to perform (find, move, and get). Section 4/ 
C.6.2.3 defines these SOP classes and their UIDs. 

4/C.6.3 - Patient/Study Only SOP Class Group 

This section describes another of the query/retrieve infor- 
mation models. There are three SOP classes associated 
with this model, and they correspond to the operations 
you're allowed to perform (find, move, and get). Section 4/ 
C.6.3.3 defines these SOP classes and their UIDs. 
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4/D 

Study Content/Notification Service Class 

This section describes the study content/notification service class, 
which basically provides a "composite" way of peforming a 
"normalized-type" operation. It provides a way for implemented 
who may not be ready to completely convert to "normalized" to still 
approximate the functionality of normalized 

4/E,4/F,4/G 

Patient Management Service Class 
Study Management Service Class 
Results Management Service Class 

These are normalized service classes - used to manage/track status 
of studies, primarily. The three classes work together to manage the 
status of the studies. 

4/H 

Print Management Service Class 

This section describes the print management service class, which 
lets you use DICOM to print images on a sheet of film. This service 
class has a set of normalized information objects that let you perform 
the print operations. 

4/H.l - Scope 

This section is a 1-sentence description of the scope of this section. 
4/H.2 - Print Management Model 

This section describes the model of printing, including film session 
management, queue management, and the actual print process itself. 
The largest section describes film session management. 

To use DICOM for printing, you do the following things: 

• use "create" to create a set of objects 

• use "set" to create a set of attributes for those objects 

• use "get" to get the attributes (check the status of the print 
session) 

• use "action" to "tell" the objects to go print themselves 

• receive information via "event" to notify you when printing is 
complete. 
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Section 4/H.2 illustrates all of these tasks. 

When you are going through 4/H, you'll notice that the section refer- 
ences IODs that were defined back in 3/C. You may have to do some 
flipping back and forth between parts to understand the information. 

SOP classes are treated differently in this print management service 
class than they are in the storage service class. For one thing, there 
are a number of SOP classes in the print management service class. 
It is a little different than the way it works in the storage service class 
where you use the same operation for many different objects. In the 
storage class, each of those objects, plus the single available opera- 
tion, forms a SOP class. 

In the print management service class, there are many objects that all 
relate to some aspect of printing, and each of these objects repre- 
sents its own SOP class. For example, some of the print management 
objects/SOP classes are: 

• film session - a group of films to be printed 

• film box - a piece of film within the film session 

• image box - an image that should print somewhere on the film 

The basic idea is that you create a session that has film boxes which, 
in turn, have image boxes. Then, you tell the session to print itself. 

At the end of this annex, section 4/H.6 contains a pseudo code 
sample that illustrates how you might accomplish this. This pseudo 
code example will also give you a framework for how the SOPs 
relate to one another. 

4/H.3 - Print Management Conformance 

This section explains how you achieve conformance for the print 
management service class. Basically, there is a "core" set of SOPs 
you must support to claim minimum conformance, and then you can 
add others to meet your needs. (You only have to support one of 
these core groups; just pick the one you want and then add options 
as needed.) 
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The required core groups are: 

• basic grayscale 

• basic color 

• referenced grayscale 

• referenced color. 

The difference between color and grayscale is self-explanatory. The 
difference between basic and referenced has to do with the way the 
referenced core groups treat the t4 pixel data" attribute of the image 
box SOP class: 

For referenced, the pixel data attribute is the UID of the composite 
image that should appear in that image box on the film. The other 
image box attributes describe how that composite image should be 
rendered for printing (e.g., a reference to a lookup table, etc.). (See 
section 4/H.3.2.) 



4/H.3.2 - Print Management Meta SOP Classes 

Collections like the "core groups" described above (things 
you must have for conformance) are called meta-SOP 
classes. 

This section contains a list of the meta-SOP classes. These 
are groups of SOPs that have one collective UID. This is 
because, if you support one of the SOPs in a meta-SOP, you 
have to support all of them (e.g, you can't have image 
boxes without film boxes and a film session). 

4/H.3.3 - Optional SOP Classes 

This section describes optional SOP classes. Once you 
support one of the meta-SOP classes (meet the minimum), 
there are options you can add, such as adding text overlay 
to images, etc. Those are negotiated separately. So, you can 
support basic print management as one level of conform- 
ance, and then add additional layers of options. 

4/H.3.4 - Conformance Statement 

This section describes what you must put into your 
conformance statement if you're going to claim conform- 
ance to the print management service class. 
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4/H.4 - Print Management SOP Class Definitions 

This section contains a description, one-by-one, of all of the SOP 
classes. It describes each SOP class as an object, and includes a set 
of operations that can be performed on each object, along with a set 
of attributes that belong to the operations. For each SOP class, there 
are the following sections (replace the x's with the number that 
matches the section you're studying): 



Section 
Number 


Description 


4/H.4.X 


Defines the SOP class 


4/H.4.X.1 


Contains the IOD description 


4/H.4.X.2 


Contains the DIMSE service group, listing the 
services that can be used with this object 


4/H.4.X.2.1 


Contains information for the N-CREATE 
service. The information is broken down 
according to attributes, status, and behavior. 


4/H.4.X.2.1.1 


Lists all of the attributes for the object that 
corresponds 10 me in-\^kcai£> service. 
Includes requirement types (e.g., U, M, C). 
The requirement types are separated according 
toSCPand SCU. 

(There are things the SCP must provide that 
the SCU doesn't have to.) 


4/H.4.X.2.1.2 


Contains the status codes that can be returned 
for the N-CREATE service. 


4/H.4.X.2.1.3 


Describes how the SCU will use this service 
on the objects. Also describes what the scp 
will do to provide this service. 



4/H.5 - Association Negotiation 

This section describes association negotiation for this service class, 
which is the "hand-shaking" you must perform to set up an associa- 
tion between two AEs who want to use this service class. Refer to 
the corresponding sections in Parts 7 and 8 for additional informa- 
tion. 
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4/H.6 - Example of Print Management SCU Session 

This section contains sample code that illustrates how you perform 
print management 

Index of Attribute Tags 

This annex is a handy reference index of attribute tags and where 
they're defined. 
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Part 5: Data Structure 
and Semantics 

5/1 

Scope and Field of Application 

This section tells what Part 5 does and doesn't specify. 

5/2 

Normative References 

This section contains normative references. 

5/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 

5/3.10 - DICOM Data Structures and Encoding 

This section describes a number of things that are used to describe 
DICOM data structures and encoding. 

5/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 

5/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in the Annexes. 
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5/6 

Value Encoding 

This section explains how you individual elements are encoded. 

5/6.1 - Support of Character Repertoires 

This section begins by explaining character sets. Messages contain 
two character sets: 

• default 

• extended repertoire. 

There are certain kind of things (IDs, etc.), that must be in the default 
character set, so you can always read them, no matter what character 
set is used for the rest of the information. The default character set 
is very similar to ASCII. 

You would use the extended character sets to encode other things 
that might change on a national basis, such as patient name, address, 
etc. 

5/6.2 - Value Representation (VR) 

This section explains value representations (VRs). A VR defines the 
format of a particular data element DICOM is very specific about 
the format of data elements, and this information is in the Table of 
DICOM Value Representations. 

This table lists the DICOM VRs, gives definitions, tells you which 
character set they use, and gives you a maximum length for them. 

In part 6 (the data dictionary), every data element has a VR. The 
Table of DICOM Value Representations in is where you find the 
definition of the different VRs. 

5/6.3 - Enumerated Values and Defined Terms 

Certain data elements are only allowed to take on certain values. 
These are called enumerated values, and they're described in this 
section. 
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5/6.4 - Value Multiplicity (VM) and Delimitation 

Value multiplicity describes how elements can have multiple values. 
It then indicates which elements can have multiple values and which 
ones cannot In the data dictionary, it tells whether elements have 
multiple values. If you want to know what that means, refer to this 
section (5/6.4). 



The Data Set 

Section 5/6 tells you how to encode individual elements; section 5/ 
7 tells you how to assemble data elements into a data set 

Every data element has a data element tag (defined in the data dictio- 
nary - it's the group/element number). They are also referenced 
throughout the standard. There are two different ways to put together 
a data set using these tags: 

• implicit VR - encoding that is the same as ACR-NEMA 2.0, in 
which you put a group, element, length, and value for every data 
element 

• explicit VR - encoding that adds an additional field that gives you 
the VR of that element (defined in the value representation table). 



Note: In section 10, which describes transfer syntaxes, one of 
these forms of encoding (explicit VR) will become two 
ways in of itself, ultimately yielding three ways to put to- 
gether a data set using the tags. 



5/7.5 - Nesting of Data Sets 

Nesting of datasets is a significant extension of the standard from 
version 2.0. It allows for a recursive structuring of datasets using a 
VR called "SQ," which stands for "sequence." Section 7.5.2 
contains several good illustrations. This is a new feature of 3.0. 

5/7.6 - Repeating Groups 

This section covers repeating groups. This has not changed from 2.0. 
5/7.7 - Retired Data Elements 

This section defines what it means to retire an element It is impor- 
tant that you read this, because certain things have been retired since 
version 2.0. 
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5/8 

Encoding of Pixel Data 

This section describes how the pixel data of the image is encoded. 
The encoding changes according to transfer syntaxes (e.g., some let 
you JPEG compress, etc.). Understanding of this is key to displaying 
images. 

5/9 

Unique Identifiers (UIDs) 

This section explains how you construct UIDs, which is a very 
important concept. Annex 5/C contains additional information about 
defining your own UIDs. 

5/10 

Transfer Syntax 

This section talks about transfer syntaxes and tells how they are 
defined and what you have to do to define them. Annex S/A actually 
defines the syntaxes; this section tells what goes into those defini- 
tions. 

5/A 

Transfer Syntax Specifications 

Each section of this annex contains a definition of a transfer syntax. 

5/A.l,5/A.2, 5/A.3, 5/A.4 

Sections 5/A.l - 5/A.3 contain simple, basic encoding. 

Section 5/A.4 describes transfer syntax for the encapsulation of 
encoded pixel data. Basically, this is a family of transfer syntaxes for 
encoding compressed pixel data. 

When you compress pixel data, you take something large and make 
it small. You have no way of knowing for sure what size it will be 
when you're finished, because every item you compress is different 

This section describes a way of packaging image data into small 
"chunks" of a known size while you're compressing the image, and 
then transferring those chunks across the wire. These are basically 
JPEG transfer syntaxes. 



©1993 Kodak Health Imaging Systems. Inc. 



4-27 



Understanding DICOM 3.0 
5/B 

Creating a Privately Defined Unique Identifier 

This section contains an example of how you might create unique 
identifiers. 

5/C 

DICOM Unique Identifier Registration Process 

This section contains the process for registering a UID to make sure 
it's unique (in the US, you have contact ANSI to get a registration 
number). If you're going to use DICOM, you must get an identifier 
for your organization. 

5/D 

Examples of Various Pixel Data and Overlay Encoding 
Schemes 

This section contains examples to help you understand section 5/8. 

5/E 

DICOM Default Character Repertoire 

This section defines the default character set. 

5/F 

Encapsulated Images as Part of a DICOM Message 

This section contains an example to help you understand JPEG 
encoding. 

5/G 

Index to Data Element Tags 

This section contains an index of data element tags. 

5/H 

Index to Transfer Syntax UIDs 

This section contains an index to transfer syntax UIDs. 
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Part 6: Data Dictionary 

This part of the spec contains the DICOM data dictionary. In 
DICOM, this is really more like an index. 

What the elements actually mean and how they relate to information 
objects is all in Parts 3 and 4 of the spec. The data dictionary is a 
master list of all of the elements as well as a registry to make sure 
that an element occurs only once. 

The ACR-NEMA 2.0 data dictionary defined what the elements 
meant However, in 3.0, it defines: 

• name of the element 

• attribute tags (group/element numbers) 

• VR (value representation; you look these codes up in part 5) 

• VM (value multiplicity). 



Registry of DICOM Unique Identifiers 

This section contains a list of all UIDs that are defined anywhere in 
the specification, along the location within the specification where 
you can find their definition.. 
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Part 7: Message Exchange 

7/1 

Scope and Field of Application 

This section tells what Part 7 does and doesn't specify. 

7/2 

Normative References 

This section contains normative references. 

7/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 

7/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 

7/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in the Annexes. 

7/6 

Service Context 

This section basically tries to relate Part 7 to the OSI stack and to the 
rest of the standard. It helps give you a framework of how the parts 
of the standard work together. 
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7/6.3 - DICOM Message Structure and Command Set 

This section explains what a message is and how it is composed of 
a command and a dataset It also describes how a dataset is encoded. 

7/6.3.1 

This section is like a small version of Part 5, except it 
applies to the command set rather than the dataset 

7/7 

Service Overview 

This section describes DIMSEs, which are basically service 
elements. DIMSEs use a set of protocols to talk to other DIMSEs. 
The fiamework for this is here in section 7/7. 

7/7.4 - Association Services 

This section contains a figure that shows how the service classes and 
information objects make use of the DIMSE service to exchange 
data. DIMSE services are broken down into normalized and 
composite: 

7/7.5 -DIMSE Services 

This section contains an overview of all DIMSE services. 

7/8 

Protocol Overview 

This section is a DIMSE protocol overview. 

7/9, 7/10 

DIMSE-C, DIMSE-N 

The "meat" of part 7 is in sections 9 and 10. These are the DIMSE- 
C and DIMSE-N specifications, respectively. If you look at 9 and 10, 
they're both broken down into three sets: 

• service spec 

• sequencing spec 

• protocol spec. 
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For every service section, there is a corresponding protocol section. 
For example, section 7/9.1.1 contains the C-STORE service, and 
section 7/9.3.1 contains the corresponding C-STORE protocol. 

You'll notice that same pattern in the DIMSE-N section (section 7/ 
10.1.1 contains the N-EVENT service and section 7/10.3.1 contains 
the corresponding N-EVENT protocol. 

Generally speaking, the service is of more interest to the user, while 
the protocol is of more interest to someone who might implement the 
service provider. 

In any case, when you're trying to understand the specification, 
you'll find yourself flipping back and forth between the two parts to 
get all of the pertinent information. That's why your understanding 
of the differences between services and protocols is so important 
(See "Services and Protocols" in Chapter 3.) 

7/A 

Application Context Usage 

This annex defines the application context name. Section 7/A.4 
defines asynchronous operation. 

7/B 

Data Element Cross-Reference 

This section contains a data element cross-reference. 



Status Type Encoding 

This section shows you how to encode statuses for responses to 
commands. What it really does is show you fields that are related to 
particular status codes. 
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7/D 

Association Negotiation 

Like some of the Association Negotiation sections in other parts of 
the spec, this one describes the process of setting up an association. 
This one contains more details than the others, and ties together 
infonnation from all of those sections. 

This, in addition to the "Setting Up an Association" section in 
Chapter 2, is the place you should spend most of your time reading 
to learn the concept. 

7/E 

Command Dictionary 

This annex contains a registry of command and their fields. 



7/F 

Usage of the P-Data service by a DICOM 
Application Entity 

This section explains usage of the pdata service by a Dicom AE, 
including a description the format for pdv's (presentation data 
values). These are the last little bit of encoding that goes between the 
pdu and the data stream. This information also appears in an annex 
of Part 8 (8/E), because Part 8 came out first. 

7/G 

Index to Application Context Name UIDs 

This section is self-explanatory. 
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Part 8: Network 
Communication Support 
for Message Exchange 

8/1 

Scope and Field of Application 

This section tells what Part 8 does and doesn't specify. 

8/2 

Normative References 

This section contains normative references. 

8/3 

Definitions 

This section contains definitions of important terms and references 
to terms in other parts of the specification. 

8/4 

Symbols and Abbreviations 

This section contains definitions of important abbreviations and 
symbols you'll see in the spec. 

8/5 

Conventions 

This section describes some of the conventions used for drawing the 
pictures in the Annexes. 

8/6 

Network Communication Support Environment 

This section establishes the relationship for using DICOM with OSI 
versus TCP/IP. TCP/IP requires a different protocol, and this section 
contains it 
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8/7 

OSI Upper Layer Service for Application Message 
Exchange 

This section defines the upper layer service that goes with the OSI 
protocol (it's the service specification). When you read this Part, 
compare it to the information in 8/9 (especially the pdu formats in 8/ 
9.3.) 

8/8 

DICOM OSI Upper Layer Profile 

This section contains the OSI protocol specification. 

8/9 

Upper Layer Protocol for TCP/IP 

This section contains the protocol specification for TCP/IP. 

8/9.1 - Use of the Transport Service Provided by TCP 

This section contains a general description of the protocol. 

8/9.2 - DICOM Upper Layer Protocol for 
TCP/IP State Machine 

This section contains the finite state machine for the protocol. 

8/9.3 - DICOM Upper Layer Protocol for 
TCP/IP Data Units Structure 

This section contains the formats of all of the pdu's (messages). 
When you read this section, compare it to the definition in 8/7. 

8/A 

Application Context Names 

This annex contains the application context names. This section is 
virtually obsolete since the release of Part 7. 
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8/B 

Abstract and Transfer Syntax Names 
Encoding and Registration. 

This section describes abstract and transfer syntaxes. As with annex 
8/A, this section is virtually obsolete since the release of Part 7. 

8/C 

DICOM Addressing 

This annex describes the relationship between application process 
titles and presentation addresses (implementation-specific). 

8/D 

Use and Format of the A-ASSOCI ATE 
User Information Parameter 

This section is no longer valid; it has been replaced by Part 7. 

8/E 

Usage of the P-Data Service by the 
Message Exchange Protocol 

This section is no longer valid; it has been replaced by Part 7. 
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Part 9: Point-to- Point 
Communication Support 
for Message Exchange 

This part of the specification addresses forward compatibility. You 
would need this information if you still want to run DICOM over the 
old, 50-pin connector. 
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Part 1 0: Media Storage 
and File Format 

This part of the specification describes file formats. These file 
formats apply for when a dataset is a file. This section is not offi- 
cially part of DICOM 3.0, but is on the horizon. 
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This chapter contains an index for the DICOM 3,0 
specification document. 

The specification document is hundreds of pages long, 
so this should prove a handy reference. 

This is NOT an index for Understanding DICQM. That 
index is in Appendix C. 



How to Use the DICOM 3.0 Spec Index: 



Terms are alphabetized Just like in any other Index. The 
references consist of : 

• the part number from the spec ( 1 /, 21, 3/, etc.). 

plus 

• the section number where you can find the 
information (2.5, 6.7.3. 1 , A.5.3.2, etc.). 



part numbers 



5/6, 



0.1 

C.7.5.1.1.1 
•1.2.2 



1/ 
3/ 
5/ 



0.1 
C.7.5.1.1.1 
6.1.2.2 



section numbers 



For example, you'd read these examples like this: 
"section 0.1 of Part 1" 

'section C. 7.5. 1 . 1 . 1 (in Appendix C) of Part 3" 
'section 6. 1.2.2 or Part 5" 
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a 



A-ABORT service 

A-ABORT-RQ 
pdu structure 

A-ASSOCIATE service 

A-ASSOCIATE-AC 

A-ASSOCIATE-AC 
pdu structure 

A-ASSOCIATE-RJ 
pdu structure 

A-ASSOCIATE-RQ 



A-ASSOCIATE-RQ 
pdu structure 

A-ASSOCIATION-AC 

abbreviations 

A-P-ABORT service 

A-RELEASE service 

A-RELEASE-RP 
pdu structure 

A-RELEASE-RQ 
pdu structure 

abstract syntaxes 

abstract syntaxes 
(network) 

ACR-NEMA 1.0 and 2.0 
purpose 1/0.1 

ACSE 

ACSE protocol requirements 
(OSI upper layer) 

ACSE service definitions 

ACSE service definitions 
(network) 



8/7.3 

8/9.3.8 
8/7.1 

4/C.5.2.1.2 
8/9.3.2 

8/9.3.3 

4/B.3.1.1 

4/C.5.1.1.1 

4/C.5.2.1.1 

8/9.3.1 

4/C.5.1.1.2 

1/4 

8/7.4 

8/7.2 

8/9.3.7 

8/9.3.6 
7/D.l 

8/B.l 
1/0.1 

1/4 

8/8.2 

2/3.2 
7/3.4 

8/3.5 



action information (N- ACTION) 

action reply (N-ACTION) 

action type ID (N-ACTION) 

address for DICOM 
comments/suggestions 

addressing, DICOM 

admit patient, patient management 
functional model 

AE specifications 

AEs, mutually exclusive, US 

AEs, mutually exclusive, 
multi-frame US 

affected SOP class instance UID 

affected SOP class UID 



affected SOP class UID 
(N-ACTION) 

affected SOP class UID 
(N -CREATE) 

affected SOP class UID 
(N-DELETE) 

affected SOP class UID 
(N-EVENT-REPORT) 

affected SOP class UID 
(N-GET) 

affected SOP class UID 
(N-SET) 

affected SOP instance UID 
(N-ACTION) 

affected SOP instance UID 
(N -CREATE) 

affected SOP instance UID 
(N-DELETE) 

affected SOP instance UID 
(N-EVENT-REPORT) 



7/10.1.4.1.6 
7/10.1.4.1.9 
7/10.1.4.1.5 

1/0.3 
8/C 

4/E.1.2.3 

2/A.2 

3/A.6.3.1 

3/A.7.3.1 

7/9.1.1.1.4 

7/9.1.1.1.3 
7/9.1.2.1.3 
7/9.1.3.1.3 
7/9.1.4.1.3 
7/9.1.5.1.3 

7/10.1.4.1.7 

7/10.1.5.1.3 

7/10.1.6.1.5 

7/10.1.1.1.3 

7/10.1.2.1.6 

7/10.1.3.1.7 

7/10.1.4.1.8 

7/10.1.5.1.4 

7/10.L6.1.6 

7/10.1.1.1.4 
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affected SOP instance UID 

(N-GET) 7/10.1.2.1.7 

affected SOP instance UID 

(N-SET) 7/10.1.3.1.8 

amendment, record, results management 
functional model 4/G. 1 .2.5 

amendment, transcribe, results management 
functional model 4/G. 1 .2.6 

amendment, approve, results management 
functional model 4/G. 1.2.7 

American College of Radiology 1/0. 1 

anatomic structure (US) 3/C.8.5.3.1.7 

angular step (NM SPECT 
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association initialization 7/A.3 

association negotiation 3/6.6 
4/6.6 
4/C.5 
4/D.2 
4/H.5 
7/7.4 
7/D 

association negotiation (normative) 4/A.5 

B.3 

association negotiation 

C-FIND SOP classes 4/C.5. 1 
C-GET SOP classes 4/C.5.3 
C-MOVE SOP classes 4/C.5.2 



acquisition) 



3/C.8.4.4.1.1 



association protocol 
association release 



7/8.2 
7/7.4.2 



annotation box 


4/H.4.4 




7/A.5 


application context definitions 


7/A.l 


associations, extended 
negotiations 


4/B.3.1 


application context name 
encoding/registration 


7/A.2 


associations, negotiations, patient management 
service class 4/E.2.1 


application context name UID index 7/G 


associations, negotiations, study management 


application context names 


8/A 


service class 


4/F.2.1 


registered 
private 


7/A.2.1 
7/A.2.2 


associations, negotiations, results management 
service class 4/G.2.1 


application context usage 


7/A 


associations 


2/5.1.4 


application data flow 


2/5.1 


asynchronous operations 


7/D.3.3.3 


application entity 


2/5.1.1 


attribute definition 




application layer structure 


7/6.2 


(normalized) 


3/C. 1.2.4 


approve amendment, results management 
functional model 4/G. 1 .2.7 


attribute identifier list 
(N-GET) 


7/10.1.2.1.5 



approve results, results management 
functional model 4/G. 1.2.4 



architecture 
ARTIM timer 
association abort 
association establishment 



1/6.8 

8/9.1.5 

7/A.6 

7/7.4.1 
7/D.3 



attribute list 
(N-GET) 
(N-SET) 



7/10.1.2.1.8 
7/10.1.3.1.6 



attribute list (N-CREATE) 7/10.1.5.1.5 

attribute matching 

(query/retrieve) 4/C.2.2.2 

attribute name (normalized) 3/C. 1 .2. 1 

attribute tag (normalized) 3/C. 1 .2.2 
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attribute tag index 3/F 
4/G 

attribute types 

(queiy/retrieve) 4/C.2.2. 1 

attributes 1/3 

attributes, general series 

descriptions 3/C.7.3.1.1 

frame of reference 3/C.7.4. 1 . 1 

general equipment 3/C.7.5. 1 . 1 

general image 3/C.7.6. 1 . 1 

image plane 3/C.7.6.2.1 

CT image descriptions 3/C.8.2. 1 . 1 

MR image descriptions 3/C.8.3 . 1 . 1 

NM image descriptions 3/C.8.4.3. 1 

US frame of reference 3/C.8.5.1.1 

overlay descriptions 3/C.9.2.1 
multi-frame overlay 

descriptions 3/C.9.3.1 

curve descriptions 3/C. 1 0.2. 1 

LUT descriptions 3/11.1.1 
SOP common descriptions 3/C. 12. 1. 1 

service classes 4/6.2 

definition (query/retrieve) 4/C.2.2 

audio module 3/C. 10.3 

audio synchronization 3/C. 10.3. 1 

axis units (curve attributes) 3/C.10.2. 1.3 



basic annotation presentation IOD 
modules 



3/B.10.2 



basic annotation presentation module 3/C. 1 3.7 
basic color image box 4/H.4.3.2 



basic color print management 
meta SOP class 



4/H.3.2.2.2 



basic film box info object definition 

(normalized) 3/B.8 

basic film box 

IOD description 3/B.8.1 

IOD modules 3/B.8.2 

presentation module 3/C. 13.3 

relationship module 3/C. 13.4 

SOP class definitions 4/H.4.2 

basic film session info object 

definition (normalized) 3/B.7 

basic film session 

IOD description 3/B.7.1 

IOD modules 3/B.7.2 

presentation module 3/C. 13.1 

relationship module 3/C. 1 3.2 

SOP class 4/H.4.1 

basic grayscale 

image box 4/H.4.3.1 
print management 

meta SOP class 4/H.3.2.2. 1 



baseline behavior of SCP 

(C-FIND) 4/C.4. 1.3.1 

(C-GET) 4/C.4.3.3.1 

(C-MOVE) 4/C.4.2.3.1 

baseline behavior of SCU 

(C-FIND) 4/C.4.1.2.1 

(C-GET) 4/C.4.3.2.1 

(C-MOVE) 4/C.4.2.2.1 

basic annotation box 

SOP class 4/H.4.4 



basic annotation presentation info 
object definition (normalized) 



3/B.10 



basic annotation presentation IOD 

description 3/B.10.1 



basic image box 

info object definition (normalized)3/B.9 
IOD description 3/B.9.1 
IOD modules 3/B.9.2 
pixel presentation module 3/C. 13.5 
relationship module 3/C. 1 3.6 

basic print job 

info object definition (normalized)3/B.l 1 
IOD description 3/B.ll.l 
IOD modules 3/B.11.2 

basic printer 

info object definition 

(normalized) 3/B.12 

IOD description 3/B.12.1 

IOD modules 3/B.12.2 

basic study 

content notification SOP class UID 4/D.4.3 
descriptor image IOD description 
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(composite) 3/A.ll.l 
descriptor image IOD entity-relationship 

model (composite) 3/A. 1 1 .2 
descriptor image IOD 

module table 3/A. 11.3 
descriptor info object definition 

(composite) 3/A. 11 

behavior 

baseline of SCU (C-FIND) 4/C.4. 1.2. 1 
extended of SCU (C-FIND) 4/C.4. 1.2.2 
baseline of SCP (C-FIND) 4/C.4. 1.3. 1 
extended of SCP (C-FIND) 4/C.4. 1.3.2 
baseline of SCU (C-MOVE) 4/C.4.2.2. 1 
extended of SCU (C-MOVE) 4/C.4.2.2.2 
baseline of SCP (C-MOVE) 4/C.4.2.3. 1 
extended of SCP (C-MOVE) 4/C.4.2.3.2 
baseline of SCU (C-GET) 4/C.4.3.2.1 
extended behavior of SCU 

(C-GET) 4/C.4.3.2.2 
baseline of SCP (C-GET) 4/C.4.3.3.1 
extended of SCP (C-GET) 4/C.4.3.3.2 
of an SCP 4/B.2.2 
of an SCU 4/B.2.1 

big endian transfer syntax 
(explicit VR) 



big endian/little endian 

bits allocated 
(CT module) 
(MR image module) 

bits stored (CT module) 

bolus/contrast module 
(normative) 

bone thermal index (US) 

break points (table, for US) 

byte ordering (big endian/ 
little endian) 



5/A.3 
5/7.3 



3/C.8.2.1.1.4 
3/C.8.3.1.1.4 

3/C.8.2.1.1.5 



3/C.7.6.4 

3/C.8.5.3.1.8 

3/C.8.5.2.1.7 

5/7.3 



commands 
elements 
stream 



1/3 
1/3 
1/3 



conformance 


1/0.1 


claim 


1/3 


construction process 


1/6.2 


CT 


1/4 


C-CANCEL-FIND-RQ 


7/9.3.2.3 


C-CANCEL-GET-RQ 


7/9.3.3.3 


C-CANCEL-MOVE-RQ 


7/9.3.4.3 


C-ECHO parameters 


7/9.1.5.1 


C-ECHO protocol 


7/9.3.5 


C-ECHO protocol procedures 9.3.5.3 


C-ECHO service 


7/9.1.5 


C-ECHO service procedures 7/9.1.5.2 


C-ECHO-RQ 


7/9.3.5.1 


C-ECHO-RSP 


7/9.3.5.2 


C-FIND, association negotiation 


for SOP classes 


4/C.5.1 


C-FIND operation 


4/C.4.1 


C-FIND parameters 


7/9.1.2.1 


C-FIND protocol 


7/9.3.2 


C-FIND protocol procedures 


7/9.3.2.4 


C-FIND SCP behavior 


4/C.4.1.3 


C-FIND SCP conformance 


4/C.6.1.2.2.1 




4/C.6.2.2.2.1 




4/C.6.3.2.2.1 


C-FIND SCU behavior 


4/C.4.1.2 


C-FIND SCU conformance 


4/C.6.1.2.1.1 




4/C.6.2.2.1.1 




4/C.6.3.2.1.1 


C-FIND service 


7/9.1.2 


C-FIND service parameters 


4/C.4.1.1 


C-FIND-RQ 


7/9.3.2.1 


C-FIND-RSP 


7/9.3.2.2 



composite objects 



1/6.3 
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C-GET, association negotiation 



for SOP classes 


4/C.5.3 


C-GET operation 


4/C.4.3 


C-GET parameters 


7/9.1.3.1 


C-GET protocol 


7/9.3.3 


C-GET protocol procedures 


7/9.3.3.4 


C-GET SCP behavior 


4/C.4.3.3 


C-GET SCP conformance 


4/C.6.1.2.2.3 




4/C.6.2.2.2.3 




4/C.6.3.2.2.3 


C-GET SCU behavior 


4/C.4.3.2 


C-GET SCU conformance 


4/C.6.1.2.1.3 




4/C.6.2.2.1.3 




4/C.6.3.2.1.3 


C-GET service 


7/9.1.3 


C-GET service parameters 


4/C.4.3.1 


C-GET-RQ 


7/9.3.3.1 


C-GET-RSP 


7/9.3.3.2 


C-MOVE, association negotiation 


for SOP classes 


4/C.5.2 


C-MOVE operation 


4/C.4.2 


C-MOVE parameters 


7/9.1.4.1 


C-MOVE protocol 


7/9.3.4 


C-MOVE protocol procedures7/9. 3.4.4 


C-MOVE SCP behavior 


4/C.4.2.3 


C-MOVE SCP conformance 


4/C.6. 1.2.2.2 




4/C.6.2.2.2.2 




4/C.6.3.2.2.2 


C-MOVE SCU behavior 


4/C.4.2.2 


C-MOVE SCU conformance 4/C.6.1.2.1.2 




4/C.6.2.2.1.2 




4/C.6.3.2.1.2 


C-MOVE service 


7/9.1.4 


C-MOVE service parameters 4/C.4.2.1 


C-MOVE-RQ 


7/9.3.4.1 



C-MOVE-RSP 7/9.3.4.2 

C-STORE parameters 7/9. 1 . 1 . 1 

C-STORE protocol 7/9.3 

C-STORE protocol procedures 7/9.3.1.3 

C-STORE service 7/9. 1 . 1 

C-STORE-RQ 7/9.3.1.1 

C-STORE-RSP 7/9.3.1.2 

calibration 

date of last 3/C.7.5.1.1.1 

time of last 3/C.7.5.1.1.1 

cancel status class 7/C.3 

cancellation (DIMSE) 7/7.5.3.3 

character repertoires 

support of 5/6.1 

encoding 5/6.1.2.3 

(default) 5/E 

character set 10/8.5 

character values, 

representation of encoded 5/6. 1 . 1 

characters, graphic 5/6. 1 .2 

characters, default repertoire 5/6. 1 .2. 1 

characters, replacement/extension 

of default repertoire 5/6. 1 .2.2 

characters, control 5/6. 1 .3 

cine module (normative) 3/C.7.6.5 

CMIS service definitions 7/3.5 

coding scheme 

designators 3/D 

pixel data/overlay 5/D 

color, palette lookup table 

descriptor 3/C.7.6.3 . 1 .5 

color image box SOP class 4/H.4.3.2 

column symmetric image 

display format 3/C. 13.3. 1.3 

command dictionary 7/E 
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common composite image 

IOD modules (normative) 3/C.7 

common equipment IE module 

(normative) 3/C.7.5 



common frame of reference info 
entry modules 

common image IE module 

common patient IE module 
(normative) 



3/C.7.4 
3/C.7.6 



3/C.7.1 
3/C.7.3 



common study IE module 

(normative) 3/C.7.2 

composite object IOD 3/6. 1 . 1 

composite objects 

CR 3/A.2 

CT 3/A.3 

MR 3/A.4 

NM 3/A.5 

US 3/A.6 

US (multi-frame) 3/A.7 

SC 3/A.8 

standalone overlay 3/A.9 

standalone curve 3/A.10 

basic study descriptor 3/A. 1 1 

standalone modality LUT 3/A. 12 

standalone VOI LUT 3/A.13 

compression (JPEG) 5/8.2.1 

conditional modules, 

composite 3/A. 1.3.2 

conformance 2/3.10 

specialized4/B.4.4 

conformance overview, study content 

notification service class 4/D.3 

conformance requirements 

patient root SOP class group 4/C.6. 1 .2 

study root SOP class group 4/C.6.2.2 

patient/study only SOP class group4/C.6.3.2 
SCU, study content notification 

service class 4/D.4.4. 1 
SCP, study content notification 

service class 4/D.4.4.2 



4/C.6.1.2 
4/C.6.2.2 
4/C.6.3.2 
(network) 8/10 

conformance statement, purpose 2/6 

conformance statement 4/A.6.3 

conformance statement application 
dataflow 2/A.l.l 

conformance statement for SCP 4/B.4.3.2 

conformance statement for SCU 4/B.4.3. 1 

conformance statement 

functional def s of AEs 2/A. 1 .2 

conformance statement requirements 4/B.4.3 

conformance statement sample 2/B 

conformance statement sequencing 

of real-world activities 2/A. 1.3 

conformance statement template 2/A 

contrast/bolus module (normative) 3/C.7.6.4 



conventions 

coordinate start value 

coordinate step value 

CR image IOD description 
(composite) 



2/5 

3/C.10.2.1.5 
3/C.10.2.1.5 



3/A.2.1 



CR image IOD entity-relationship 



model (composite) 

CR image module 

CR info object definition 
(composite) 

CR modules 

CR series module 

cranial thermal index (US) 



3/A.2.2 
3/C.8.1.2 

3/A.2 
3/C.8.1 
3/C.8.1.1 
3/C.8.5.3.1.8 



conformance requirements 



2/7 



create patient, patient management 

functional model 4/E. 1 .2. 1 

create results, results management 

functional model 4/G. 1.2.1 
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create study, study management 

functional model 4/F. 1 .2. 1 

create study component instance, operations, 
study component mangement 
SOP class 4/F.4.2.1 

CT image attribute descriptions 3/C.8.2. 1 . 1 

CT image IOD description 

(composite) 3/A.3.1 

CT image IOD entity-relationship 

model (composite) 3/A.3.2 

CT image IOD module table 3/A.2.3 

3/A.3.3 



data element structure (explicit VR) 5/7. 1 .2 



CT image module 



data dictionary 

data dictionary (media) 

data dictionary (symbols 
and abbreviations) 

data dictionary extension 

data element 

data element cross reference 
data element fields 



3/C.8.2.1 



CT info object definition 

(composite) 3/A.3 

CT modules 3/C.8.2 

curve attribute descriptions 3/C. 1 0.2. 1 

curve data (curve attributes) 3/C. 10.2. 1 .4 

curve data descriptor 3/C.10.2.1.5 

curve identification module 3/C. 1 0. 1 

curve IE 3/A. 1.2.8 

curve modules 3/C. 10 



1/3, 

1/6.6 

6/1 

10/A 



6/4 

10/C 

1/3 

7/B 

5/7.1 



data element structure 
(with implicit VR) 

data element tags (index) 

data element tags (private) 

data element type 



5/7.1.3 
5/G 
5/7.8.1 
5/7.4 



data element VR rules (private) 5/7.8.2 

data elements, pixel data encoding 5/8. 1 

data elements, registry 6/6 

data elements 5/7 

data elements (private) 5/7.8 

data elements (retired) 5/7.7 

data elements (type 1 required) 5/7.4.1 

data elements (type 1C conditional) 5/7.4.2 

data elements (type 2 required) 5/7.4.3 

data elements (type 2C conditional) 5/7.4.4 

data elements (type 3 optional) 5/7.4.5 

data flow model, print management 4/H.2. 1 

data flow model, globabl data flow 

model, print management 4/H.2. 1 . 1 

data flow model, grayscale transformation, 

print management 4/H.2. 1.2 



data format layer 
data set 

data set encapsulation 
data sets (nesting) 
data stream 

data structures and encoding 

data type, region (US) 

data value representation 
(curve attributes) 



10/6.2.3 

1/3 
7/9.1.1.1.8 

10/7.2 

5/7.5 

1/3 

5/1 

3/C.8.5.2.1.2 
3/C.10.2.1.2 
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datasets 5/7 

date of last calibration 

(normative) 3/C.7.5. 1.1.1 

derivation description 3/C.7.6. 1 . 1 .3 

description, print management 

meta SOP classes 4/H.3.2. 1 

description, SOP classes, optional, 

print management service class 4/H.3.3. 1 

designators, coding scheme 3/D 

detached interpretation management 
SOP class 4/G.4 

detached interpretation 

managment SOP class UID 4/G.4.4 

detached patient management 

meta SOP class 4/E.5 

detached patient management 

meta SOP class UID 4/E.3 
4/E.3.4 
4/E.5.1 
4/G.5 
4/G.5.1 

detached results management 

SOP class 4/G.3 

detached results management 

SOP class UID 4/G.3.4 

detached study management 

SOP class 4/F.3 

detached study management 

SOP class UID 4/F.3.4 

detached visit managment 

SOP class UID 4/E.4.4 

DICOM 

addressing 8/3 

application layer structure 7/6.2 

basic file service 10/8 

communication model 1 0/6. 1 

communication support defs 8/3.6 

conformance 2/3.10 

data dictionary 6/3.4 

data elements, registry 6/6 

data structure/encoding defs 2/3.7, 
3/3.5 



defined and registered UIDs 5/9.2.1 
definition 1/0.2, 4 

file format 10/7 
file meta info header 10/7. 1 

future 1/0.3 
goals 1/5 
information model 3/6 

3/7.1 
4/7.1 

information object definitions 2/3.5 

3/3.8 

introduction and overview defs 2/3.4 

3/3.3 

media storage dir info model 1 0/B.4 
media storage model 10/6.2 
message exchange definitions 2/3.8 

3/3.6 

model of the real world 4/7 
limitations 1/1 
overview of spec 1/6 
protocol architecture 1/6.8 
purpose 1/0.2 
real-world model 3/7 
scope/field of application 1/1 
service class spec definitions 2/3.6 
3/3.4 

UIDs, registry 6/A 
upper layer service 

definitions 2/3.9 
3/3.7 

DICOMDIR file, mapping into 10/B.2.3 

DICOMDIR file id (reserved) 10/8.6 

DICOMDIR file requirements 10/B.6 

DIMSE (cancellation) 7/7.5.3.3 

DIMSE procedures 7/7.5.3 

DIMSE protocol 7/8.1 

DIMSE service group, detached 

patient management SOP class 4/E.3 . 1 

DIMSE service group, detached 

visit management SOP class 4/E.4. 1 

DIMSE service group, detached 

study management SOP class 4/F.3.1 

DIMSE service group, study component 
management SOP class 4/F.4. 1 



DIMSE service group, detached results 
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management SOP class 



4/G.3.1 



DIMSE service group, detached interpretation 
management SOP class 4/G.4. 1 



DIMSE service group 
1.2 

DIMSE service group 



DIMSE service group 



DIMSE-C service group 
(normative) 

DIMSE-C service groups 

DIMSE-C services 



DIMSE-N 
DIMSE-N services 



4/H.4. 



4/H.4.2.2 

4/H.4.3.1.2 

4/H.4.3.2.2 

4/H.4.3.3.2 

4/H.4.4.2 

4/H.4.5.2 

4/H.4.6.2 

4/H.4.7.2 

4/H.4.8.22 



3.64 
4/6.4 



DIMSE service-user interaction 7/7.2 
DIMSE services 7/7.5 
DIMSE-C 7/9 



4/A.3 

4/C.4 

3/6.3.1 
4/6.3.1 
7/7.5.1 

7/10 

3/6.3.2 
4/6.3.2 
7/10 
7/10.1 
7/7.5.2 

directory info mapping 1 0/B.2.3 

directory info objects defs (basic) 10/B.3 

directory information object 

modules 10/B.3.2 

directory record header module 10/B.3.2.3 

directory record type specific modules 10/B.5 

discharge patient, patient management 

functional model 4/E.1.2.5 



disrupted procedures 7/10.2.3 

disrupted procedures (sequencing) 7/9.2.3 

disrupting procedures 7/10.2.4 

disrupting procedures (sequencing) 7/9.2.4 



E/R model, patient root SOP 

class group 4/C.6. 1.1.1 

E/R model, study root SOP 

class group 4/C.6.2. 1 . 1 

E/R model, patient/study only 

SOP class group 4/C.6.3.1.1 



encapsulated images (as part of message) 5/F 


encapsulated JPEG images 


5/F.l 


encapsulation rules 


7/F.l 


encoding, native or encapsulated 


5/8.2 


encoding, status type 


7/C 


encoding (rules for UIDs) 


5/9.1 


encoding pixel data 


5/8 


encoding rules 


5/7.5.1 


entity (service classes) 


4/5.1.1 


entity-relationship model 


3/5.1 


entity-relationship model 




(service classes) 


4/5.1 


entity/relationship model definition 


(query/retrieve) 


4/C.2.1 


equipment IE 


3/A. 1.2.4 


event information 




(N -EVENT-REPORT) 


7/10.1.1.1.6 


event reply 




(N-EVENT-REPORT) 


7/10.1.1.1.7 


event type ID 




(N-EVENT-REPORT) 


7/10.1.1.1.5 
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execution status information 

(DIMSE, print job) 4/H.4.5.3 

extended behavior of SCP 

(C-FIND) 4/C.4. 1.3.2 

extended behavior of SCP 

(C-GET) 4/C.4.3.3.2 

extended behavior of SCP 

(C-MOVE) 4/C.4.2.3.2 

extended behavior of SCU 

(C-FIND) 4/C.4. 1.2.2 

extended behavior of SCU 

(C-GET) 4/C.4.3.2.2 

extended behavior of SCU 

(C-MOVE) 4/C.4.2.2.2 

extended notifications, SCU conformance, 
specialized SOP class conformance, 
patient management 
service class 4/E.6.3.3 

extended notifications, SCU conformance, 
specialized SOP class conformance, 
study management 
service class 4/F.6.3.3 

extended notifications, SCU conformance, 
specialized SOP class conformance, 
patient management 
service class 4/G.6.3.3 



failure status class 7/C.5 

file content access 1 0/8.4 

file format (and media storage) 10/1 

file format (DICOM) 10/7 

file id (reserved DICOMDIR) 10/8.6 

file Ids 10/8.2 

file management information, 

support of 10/7.3 



file management roles 
file meta info header 
file reference module 



10/8.3 
10/7.1 
10/B.3.2.5 



file service, basic DICOM 10/8 
file-set 10/8.1 
file-set ID module 10/B.3.2. 1 

film box, SOP class definitions 4/H.4.2 
film session, SOP class 4/H.4. 1 

film session dir record keys defs 10/B.5.9 
flags, region (US) 3/C.8.5.2.1.3 
format, image display 3/C. 1 3.3. 1 

format, image display (standard) 3/C. 13.3. 1.1 
format, row symmetric image 



display 



3/C.13.3.1.2 



format, column symmetric image 

display 3/C.13.3.1.3 

frame increment pointer 3/C.8.4.3 .1.1 

frame increment pointer (US) 3/C.8 J.3.1.4 

frame increment pointer/number 

of frames 3/C.7.6.6. 1 . 1 

frame of reference attribute 

descriptions (normative) 3/C.7.4.1.1 



frame of reference IE 



3/A. 1.2.5 



frame of reference module 

(normative) 3/C.7.4.1 

frame of reference UID 

(normative) 3/C.7.4. 1.1.1 

frame time 3/C.7.6.5. 1 . 1 

frame time vector 3/C.7.6.5. 1 .2 

frames, number in overlay 3/C.9.3 . 1 . 1 



functional models, pari 
management 



4/E.1.2 



functional models, study 

management 4/F.1.2 
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functional models, results 

management 4/G. 1.2 



g 



general directory info module 



10/B.3.2.2 



general equipment attribute description 

(normative) 3/C.7.5.1.1 

general equipment module 

(normative) 3/C.7.5.1 

general image attribute 

descriptions 3/C7.6. 1. 1 

general image module 3/C.7.6. 1 

general modules 3/C. 1 2 

general series attribute descriptions 

(normative) 3/C.7.3.1.1 



general series module 
(normative) 

general study module 
(normative) 



3/C.7.3.1 



3/C.7.2.1 



get interpretation information, operations, 
detached interpretation 
management SOP class 4/G.4.2. 1 

get patient information, operations, 
detached patient mangement 
SOP class 4/E.3.2.1 

get results information, operations, 
detached results mangement 
SOP class 4/G.3.2.1 

get study component information, 

operations, study component mangement 
SOP class 4/F.4.2.3 

get study information, operations, detached 
study mangement SOP class 4/F.3.2. 1 

get visit information, operations, detached 
visit management SOP class 4/E.4.2. 1 

global data flow model, print management 



model 
graphic characters 
grayscale image box 



4/H.2.1.1 

5/6.1.2 

4/H.4.3.1 



grayscale transformations, print 

management data flow model 4/H.2. 1.2 



group length 
groups, repeating 

h-i 

HIS 
history 

informatics, medical 

information object 
class 

definitions 
instance 

header, file meta info 

hierarchical search method 

high bit (CT module) 

icon image module 

identifier 

identifier (C-FIND operation) 

identifier (C-GET operation) 

identifier (C-MOVE operation) 

IE, patient 

IE, study 

IE, series 

IE, equipment 

IE, frame of reference 

IE, image 



5/7.2 
5/7.6 



1/4 

1/0.1 

1/1 

1/3 
1/3 
1/6.3 
1/3 

10/7.1 

4/C.4.1.3.U 

3/C.8.2.1.1.6 

10/B.7 

7/9.1.2.1.4 
7/9.1.3.1.5 
7/9.1.4.1.6 

4/C.4.1.1.3 

4/C.4.3.1.3 

4/C.4.2.1.4 

3/A. 1.2.1 

3/A.1.2.2 

3/A. 1.2.3 

3/A. 1.2.4 

3/A. 1.2.5 

3/A. 1.2.6 
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IE, overlay 3/A. 1.2.7 

IE, curve 3/A. 1.2.8 

image box SOP class 4/H.4.3 

image compression 5/8.2.1 

image dir record keys defs 10/B.5.4 

image display format (basic 

film box pres.) 3/C. 13.3.1 

image display format 

(standard) 3/C.13.3.1.1 

image IE 3/A. 1.2.6 

image level, patient root SOP 



class group 



4/C.6. 1.1.5 



image level, study root SOP 

class group 4/C.6.2.1.4 

image overlay box info object 

definition (normalized) 3/B.14 

image overlay box IOD 

description 3/B.14.1 

image overlay box IOD 

modules 3/B.14.2 

image overlay box presentation 

module 3/C.13.10 

image overlay box relationship 

module 3/C.13.11 



image overlay box 
SOP class 

image pixel attribute 
descriptions 



4/H.4.8 
3/C.7.6.3.1 



image pixel module 

(normative) 3/C.7.6.3 

image plane attribute 

descriptions 3/C.7.6.2.1 

image plane module 

(normative) 3/C.7.6.2 

image position 

(basic image box pixel) 3/C. 1 3.5. 1 

image position/orientation 3/C .7.6.2. 1 . 1 



image transformation 

matrix (US) 3/C.8.5.3.1.9 

image translation vector (US) 3/C.8.5.3.1.9 

image type 3/C.7 .6. 1 . 1 .2 

image type (CT module) 3/C.8.2.1.1.1 

image type (MR image 



module) 
image type (US) 



3/C.8.3.1.1.1 
3/C.8.5.3.1.1 



information model, patient root 

query/retrieve 4/C.6.1.1 

information model, study root 

query/retrive 4/C.6.2.1 

information model, patient/study only 
query/retrive 4/C.6.3.1 

information model, patient 

management 4/E.1.3 

information model, study 

management 4/F.1.3 

information model, results 

management 4/G.1.3 

information model definition 

(query/retrieve) 4/C.2 

information models (patient root 
query/retrieve) 4/C.3 . 1 

information models (patient/study only 
query/retrieve) 4/C.3.3 

information models (study root 
query/retrieve) 4/C.3.2 

information module definitions 
(normative) 3/C 

information object, medical 

definitions 10/6.2.3.1 

information object, medical 

info directories 10/6.2.3.2 

information object attributes 3/6.2 

information object definitions. 



composite 



3/A 
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information object definitions, 

specialized 4/B.4.4.2 

information object definitions 3/3, 6 

information object definitions, 

normalized 3/B 



initiating AE 



7/9.1.1.1.6 



interpretation approval module 

(normative) 3/C.6.6 

interpretation identification module 
(normative) 3/C.6.2 

interpretation info object definition 
(normalized) 3/B .6 

interpretation IOD description 3/B.6. 1 

interpretation IOD modules 3/B .6.2 

interpretation IOD subset specification, 
get interpretation information 4/G.4.2.1.1 

interpretation IOD subset specification, 
set interpretation information 4/G.4.2.2.1 



interpretation modules 
(normative) 



3/C.6 



interpretation recording module 

(normative) 3/C.6.4 

interpretation relationship module 

(normative) 3/C.6.1 



interpretation state module 
(normative) 



3/C.6.3 



interpretation transcription module 
(normative) 3/C.6.5 

IOD, CR description 

(composite) 3/A.2.1 

IOD, CT description (composite) 3/A.3. 1 

IOD, MR description (composite) 3/A.4. 1 

IOD, NM description (composite) 3/A.5. 1 

IOD, US description (composite) 3/A.6. 1 

IOD, US multi-frame description 



(composite) 



3/A.7.1 



IOD, SC description (composite) 3/A.8. 1 

IOD, standalone overlay description 

(composite) 3/A.9.1 

IOD, standalone curve description 

(composite) 3/A.10.1 

IOD, basic study descriptor description 

(composite) 3/A.ll.l 

IOD, standalone modality LUT description 
(composite) 3/A.12.1 

IOD, standalone VOI LUT description 

(composite) 3/A.13.1 

IOD, patient description 

(normalized) 3/B.l.l 

IOD, patient modules (normalized) 3/B. 1.2 

IOD, visit description (normalized) 3/B.2.1 

IOD, visit modules (normalized) 3/B. 2. 2 

IOD, study description (normalized) 3/B.3.1 

IOD, study modules (normalized) 3/B.3.2 

IOD, study component description 



(normalized) 



3/B.4.1 



IOD, study component modules 

(normalized) 3/B.4.2 

IOD, results description 

(normalized) 3/B.5.1 

IOD, results modules (normalized) 3/B. 5. 2 

IOD, interpretation description 

(normalized) 3/B.6.1 



IOD, interpretation modules 
(normalized) 



3/B.6.2 



IOD, basic film session description 

(normalized) 3/B.7.1 

IOD, basic film session modules 

(normalized) 3/B.7.2 

IOD, basic film box description 

(normalized) 3/B.8.1 



IOD, basic film box modules 
(normalized) 



3/B.8.2 
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IOD, basic image box description 

(normalized) 3/B.9.1 

IOD, basic image box modules 

(normalized) 3/B.9.2 

IOD, basic annotation presentation 

description (normalized) 3/B. 10. 1 

IOD, basic annotation presentation 

modules (normalized) 3/B. 10.2 

IOD, basic print job description 

(normalized) 3/B.U.l 

IOD, basic print job modules 

(normalized) 3/B. 11.2 

IOD, basic printer description 

(normalized) 3/B.12.1 

IOD, basic printer modules 

(normalized) 3/B.12.2 

IOD, VOI LUT description 

(normalized) 3/B.13.1 



IOD, VOI LUT modules 
(normalized) 



3/B.13.2 



IOD, image overlay box description 
(normalized) 3/B.14.1 

IOD, image overlay box modules 

(normalized) 3/B.14.2 

IOD basic study descriptor entity-relationship 
model (composite) 3/A. 1 1 .2 

IOD CR entity-relationship model 

(composite) 3/A.2.2 

IOD CT entity-relationship model 

(composite) 3/A.3.2 



IOD description, composite 
IOD description 



3/A.l.l 

4/H.4.1.1 

4/H.4.2.1 

4/H.4.3.1.1 

4/H.4.3.2.1 

4/H.4.3.3.1 

4/H.4.4.1 

4/H.4.5.1 

4/H.4.6.1 

4/H.4.7.1 

4/H.4.8.1 



IOD entity-relationship model 3/A. 1.2 

IOD module table, composite 3/A. 1.3 

IOD MR entity-relationship model 
(composite) 3/A.4.2 

IOD NM entity-relationship model 
(composite) 3/A.5.2 

IOD SC entity-relationship model 

(composite) 3/A.8.2 

IOD standalone curve entity-relationship 
model (composite) 3/A. 10.2 

IOD standalone modality LUT entity-relationship 
model (composite) 3/A. 12.2 

IOD standalone overlay entity-relationship 
model (composite) 3/A.9.2 

IOD standalone VOI LUT entity-relationship 
model (composite) 3/A. 1 3 .2 

IOD subset specifications, patient, 

get patient information 4/E.3 .2. 1 . 1 

IOD subset specifications, study, 

get study information 4/F.3 .2. 1 . 1 

IOD subset specifications, study, 

set study information 4/F.3 .2.2. 1 

IOD subset specifications, study component, 
create study component instance 4/F.4.2. 1 . 1 

IOD subset specifications, study, set 

study information 4/F.4.2.2. 1 

IOD subset specifications, study component, 
get study component information 4/F.4.2.3.1 

IOD subset specifications, results, get 

results information 4/G.3.2. 1 . 1 

IOD US entity-relationship model 

(composite) 3/A.6.2 

IOD US multi-frame entity-relationship 
model (composite) 3/A.7.2 
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j-i 



JPEG, transfer syntax for 

JPEG image compression 

JPEG image compression 
(transfer syntaxes) 

keys t unique 

keys, required 

keys, optional 

layer, physical media 

layer, media format 

layer, data format 



5/10.2 
10.3 

5/8.2.1 



5/A.4.1 

4/C.2.2.1.1 

4/C.2.2.1.2 

4/C.2.2.1.3 

10/6.2.1 

10/6.2.2 

10/6.2.3 



list of SOP classes, SOP classes, optional, print 
management service class 4/H.3.3.2 



list of UID matching 



4/C.2.2.2.2 



little endian transfer syntax (explicit VR) 

5/A.2 



little 



transfer syntax (implicit VR) 
5/A.l 



local relationships 2/5.1.3 
lookup table (LUT) modules 3/C. 1 1 
lower level dir entity offset module 10/B.3.2.4 



LUT attribute descriptions 
LUT descriptor 

m 

medical informatics 

message 
class 



machine states definition 



3/11.1.1 
C.1 1.2.1 

3/11.1.1.1 



1/1 

1/3 
1/3 
1/6.7 

8/9.2.1 



mandatory modules, composite 


3/A. 1.3.1 


matching 




value 


4/C.2.2.2.1 


UID 


4/C.2.2.2.2 


universal 




wildcard 


4IC222A 


range 


4/C.2.2.2.5 


sequence 


4/C.2.2.2.6 


multiple values 


4/C.2.2.3 


maximum length negotiation 


8/D 


mechanical index (US) 


3/C.8.5.3.1.8 


media format layer 


10/6.2.2 


media storage and file format 


lO/l 


application profiles 


10/6.2.4 


data HirtinnAFV 


10/A 


media storage dir 




and file-set id 


10/B 


info model 


IO/B.4 


dir organization 


IO/B.2.1 


sample 


IO/B.2.2 


message control header encoding 11?. 2 


message exchange 


111 


message ID (C-ECHO) 


7/9.1.5.1.1 


(C-FIND) 


7/9.1.2.1.1 


(C-GET) 


7/9.1.3.1.1 


(C-MOVE) 


7/9.1.4.1.1 


(C-STORE) 


7/9.1.1.1.1 


(move originator) 


7/9.1.1.1.7 


(N-ACTION) 


7/10.1.4.1.1 


(N -CREATE) 


7/10.1.5.1.1 


(N -DELETE) 


7/10.1.6.1.1 


(N-EVENT-REPORT) 


7/10.1.1.1.1 


(N-GET) 


7/10.1.2.1.1 


(N-SET) 


7/10.1.3.1.1 


message ID being responded to 


7/9.1.1.1.2 


message ID being responded to 


7/9.1.2.1.2 




7/9.1.3.1.2 




7/9.1.4.1.2 




7/9.1.5.1.2 


message ID being responded to 




(N-ACTION) 


7/10.1.4.1.2 


(N -CREATE) 


7/10.1.5.1.2 


(N-DELETE) 


7/10.1.6.1.2 


(N-EVENT-REPORT) 


7/10.1.1.1.2 
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(N-GET) 7/10.1.2.1.2 
(N-SET) 7/10.1.3.1.2 



meta classes, SOP, detached patient management 

4/G.5 

UID 4/G.5.1 

meta classes, SOP, print management 4/H.3.2 
basic grayscale print management 

4/H.3.2.2.1 

meta classes, SOP, basic color print management 

4/H.3.2.2.2 

meta classes, SOP, referenced grayscale print 
management 4/H.3.2.2.3 

meta classes, SOP, referenced color print 

management 4/H.3.2.2.4 

meta service-object pair group ID 7/D. 1 .2 

meta SOP class definitions, print management 
met SOP classes 4/H.3.2.2 

meta SOP classes, detached patient management 

4/E.5 

meta SOP classes, detached patient management 

UID4/E.5.1 

meta SOP classes, study management 4/F.5 
UID 4/F.5.1 

meta SOP classes, detached patient management 

4/G.5 

UID 4/G.5.1 

meta SOP classes, print management4/H.3.2 

meta SOP classes, basic grayscale print 
management 4/H.3.2.2.1 

meta SOP classes, basic color print management 

4/H.3.2.2.2 

meta SOP classes, referenced grayscale print 
management 4/H.3.2.2.3 



meta SOP classes, referenced color print 
management 4/H.3.2.2.4 

3/C.7.3.1.1.1 
3/11.1 
3/11.1.12 

3/C.8 

7/10.1.3.1.5 



module, curve identification 3/C. 1 0. 1 

definitions (normative) 3/C 

table 10/B.3.1 

modules 

mandatory composite 3/A. 1 .3. 1 

conditional composite 3/A. 1 .3.2 

user option composite 3/A. 1.3.3 

patient (normalized) 3/B . 1 2 

visit (normalized) 3/B .2.2 

study (normalized) 3/B.3.2 

study component (normalized) 3/B .4.2 

results (normalized) 3/B .5 .2 

interpretation (normalized) 3/B.6.2 

basic film session (normalized) 3/B .7.2 

basic film box (normalized) 3/B.8.2 

basic image box (normalized) 3/B.9.2 
basic annotation presentation 
(normalized) 

3/B.10. 

basic print job (normalized) 3/B. 1 1.2 

basic printer (normalized) 3/B. 12.2 

VOI LUT (normalized) 3/B.13.2 

image overlay box (normalized) 3/B. 14.2 

patient(normative) 3/C.2 

visit (normative) 3/C.3 

visit relationship (normative) 3/C.3 . 1 

visit identification (normative) 3/C.3.2 

visit status (normative) 3/C.3.3 

visit admission (normative) 3/C.3.4 

visit discharge (normative) 3/C.3.5 

visit scheduling (normative) 3/C.3.5 

study (normative) 3/C.4 

study relationship (normative) 3/C.4. 1 

study identification (normative) 3/C.4.2 

study module (normative) 3/C.4.3 
study scheduling (normative) 3/C.4. 
study acquisition (normative) 3/C.4.5 
study read (normative) 3/C.4.6 
study component (normative) 3/C4.7 
study component relationship 

(normative) 3/C.4.8 



study component status (normative) 3/C.4.9 



message structure and command set 7/6.3 Modality 

LUT module 

meta classes, SOP, detached patient management type 

4/E.5 

UID 4/E.5.1 modality-specific modules 

meta classes, SOP, study management 4/F.5 

Uid 4/F.5.1 modification list (N-SET) 
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modules (continued) 

results (normative) 3/C.5 
results relationship (normative) 3/C.5. 
results identification (normative) 3/C.5.2 
results impressions (normative) 3/C.5.3 
interpretation (normative) 3/C.6 
interpretation relationship(normative)3/C.6.1 
interpretation identification (normative) 

3/C.6.2 

interpretation state (normative) 3/C.6.3 
interpretation recording (normative) 3/C.6.4 
interpretation transcription (normative) 

3/C.6.5 

interpretation approval (normative) 3/C.6.6 
common composite image IOD 



(normative) 3/C.7 

patient (normative) 3/C.7. 1 . 1 

common study IE (normative) 3/C.7. 

general study (normative) 3/C.7.2.1 

patient study (normative) 3/C.7.2.2 

common series IE (normative) 3/C.7.3 

general series (normative) 3/C.7.3.1 



general series attribute (normative) 

3/C7.3.1.1 
frame of reference (normative) 3/C.7.4. 1 
common equipment IE (normative) 3/C.7.5 



general equipment (normative) 3/C.7.S.1 

general image (normative) 3/C.7.6.1 
common image IE (normative) 3/C.7.6.1 

image plane (normative) 3/C.7.6.2 

image pixel (normative) 3/C.7.6.3 

contrast/bolus (normative) 3/C.7.6.4 

cine (normative) 3/C.7.6.5 

multi-frame (normative) 3/C.7.6.6 

patient summary (normative) 3/C.7.7 

study content (normative) 3/C.7.8 

modality-specific 3/C.8 

CR 3/C.8.1 

CT 3/C8.2 

MR 3/C8.3 

NM 3/C.8.4 

NM series 3/C.8.4.1 

NM equipment 3/C8.4.2 

NM image 3/C.8.4.3 

NMSPECT 3/C.8.4.4 

NM multi-gated acquisition 3/C.8.4.5 

US frame of reference 3/C.8.5.1 

US region calibration 3/C.8.5.2 

US image 3/C.8.5.3 

secondary capture 3/C.8.6 

SC equipment 3/C.8.6.1 

SC image 3/C.8.6.2 

overlay 3/C.9 



overlay identification 3/C.9.1 

overlay plane 3/C.9.2 

curve 3/C.l 

audio 3/C.10.3 

LUT 3/C.l 1 

VOILUT 3/C.l 1.2 

general 3/C.12 

SOP common 3/C.12.1 

print management 3/C. 1 3 

basic film session presentation 3/C. 13.1 

basic film session relationship 3/C. 1 3. 

basic film box presentation 3/C. 13.3 

basic film box relationship 3/C. 1 3.4 
basic image box pixel presentation 3/C. 1 3.5 

basic image box relationship 3/C. 1 3.6 
basic annotation presentation module 

3/C.13.8 

printer 3/C.13.9 

image overlay box presentation 3/C. 1 3. 10 

image overlay box relationship 3/C. 13.11 

modules (directory info object) 10/B.3.2 

modules (directory record header) 10/B.3.2.3 

modules (file reference) 10/B.3.2.5 

modules (file-set ID) 10/B.3.2. 1 

modules (general directory info) 10/B.3.2.2 

modules (icon image) 10/B.7 

modules (lower level dir entity offset) 10/B. 3. 2.4 

move destination 7/9. 1 .4. 1 .5 

(C-MOVE operation) 4/C.4.2.1.3 

move originator AE title 7/9. 1 . 1 . 1 .6 

move originator message ID 7/9. 1 . 1 . 1 .7 

MR image attribute descriptions 3/C.8.3. 1 . 1 

MR image IOD description 

(composite) 3/A.4.1 

MR image IOD entity-relationship model 

(composite) 3/A.4.2 

MR image IOD module table 3/A.4.3 

MR image module 3/C.8.3.1 



MR info object definition (composite) 3/A.4 
multi-fram overlay attribute descriptions 
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3/C.9.3.1 


(DIMSE, image overlay box) 


4/H.4.8.2.3 






parameters 


7/10.1.6.1 


multi -frame attribute descriptions 




protocol 


7/10.3.6 






protocol procedures 


7/10.3.6.3 


(cine module) 


3/C.7.6.5.1 


service 


7/10.1.6 


module (normative) 


3/C.7.6.6 


service procedures 


7/10.1.6.2 


overlay module 


3/C.9.3 








N-DELETE-RQ 


7/10.3.6.1 


multiple responses (DIMSE) 


7/7.5.3.2 








N-DELETE-RSP 


7/10.3.6.2 






N-EVENT-REPORT 








(DIMSE, print job) 


4/H.4.5.2.1 


n 




(DIMSE, printer) 


4/H.4.6.2.1 






panuneiers 


7/10 1 1 1 

// 1V/.1.1. 1 


National Electrical Manufacturers Assn. 


protocol 


7/10.3. 




1/0.1 


protocol procedures 


7/10.3.1.3 






service 


7/10.1.1 


network interface unit (NIU) 


i in i 
1/U.l 


SCI v ice piuwuurcs 


7/10 12 2 


networked environment in DICOM 


1/0.1 


N-EVENT-REPORT-RQ 


7/10.3.1.1 


normalized objects 


1/6.3 


N-EVENT-REPORT-RSP 


7/10.3.1.2 


NIU 


1/4 


N-GET (DIMSE, print job) 


4/H.4.5.2.5 


N-ACTION (DIMSE, film session) 




(DIMSE, printer) 


4/H.4.6.2.5 


4/H A 1 0 A 


parameters 


7/10.1.2.1 




protocol 


7/10.3.2 


(DIMSE, film box) 


4/H.4.2.2. 


protocol procedures 


7/10.3.2.3 


parameters 


7/10.1.4.1 




protocol 


7/10.3.4 




7/10.1.2 


U1UUAA/1 UlUltvUUlva 


7/10.3.4.3 






service 


7/10.1.4 


N-GET service procedures 


7/10.1.2.2 


service procedures 


7/10.1.4.2 








N-GET-RQ 


7/10.3.2.1 


N-ACTION-RQ 


7/10.3.4.1 








N-GET-RSP 


7/10.3.2.2 


N-ACTION-RSP 


7/10.3.4.2 








N-SET (DIMSE, film session) 


4/H.4.1.2.2 


N-CREATE (DIMSE, film session) 


4/H.4.1.2.1 


(DIMSE, film box) 


4/H.4.2.2.2 


(DIMSE, VOI LUT) 


4/H.4.7.2.1 


(DIMSE, image box) 


4/H.4.3. 1.2.1 


(DIMSE, image overlay box) 


4/H.4.8.2.1 


(DIMSE, color image box) 


4/H.4.3.2.2. 


(DIMSE film box) 


4/H.4.2.2.1 


(DIMSE, referenced image box) 


parameters 


7/10.1.5.1 




4/H.4.3.3.2.1 


protocol 


7/10.3.5 


(DIMSE, annotation box) 


4/H.4.4.2.1 


protocol procedures 


7/10.3.5.3 


(DIMSE, VOI LUT) 


4/H.4.7.2. 


service 


7/10.1.5 


(DIMSE, image overlay box) 


4/H.4.8.2.2 


service procedures 


7/10.1.5.2 


parameters 


7/10.1.3.1 






protocol 


7/10.3.3 


N-CREATE-RQ 


7/10.3.5.1 


protocol procedures 


7/10.3.3.3 


N-CREATE-RSP 


7/10.3.5.2 


N-SET (continued) 








service 


7/10.1. 


N-DELETE (DIMSE, film session) 


4/H.4.1.2. 


service procedures 


7/10.1.3.2 


(DIMSE, film box) 


4/H.4.2.2.3 




(DIMSE, VOI LUT) 


4/H.4.7.2.3 


N-SET-RQ 


7/10.3.3.1 



©1993 Kodak Health Imaging Systems, Inc. 



A- 19 



Understanding DICOM 3.0 



N-SET-RSP 

naming and addressing 
(OSI upper layer) 
conventions (network) 



7/10.3.3.2 



8/8.1 
8/3.2 



NM multi-gated acquisition image module 

3/C.8.4.5 



negotiations, extended for associations 4/B.3.1 
association 4/C.5 
association for C-FIND SOP classes 4/C.5. 1 
extended for SOP classes 4/C.5.1.1 
SOP classes, C-FIND, extended 
for sub-item structure 
(A-ASSOCIATE-RQ) 4/C.5. 1. 1. 1 
(A-ASSOCIATE-AQ 4/C.5. 1. 1. 
association for C-MOVE SOP classes 

4/C.5.2 

extended for SOP classes (C-MOVE) 

4/C.5.2.1 

SOP classes, C-MOVE, extended 
for sub-item structure 
(A-ASSOCATE-RQ) 4/C.5.2. 1. 1 

(A-ASSOCIATE-AQ 4/C.5.2. 1.2 

association for C-GET SOP classes 

4/C.5.3 

extended for SOP classes (C-GET) 

4/C.5.3.1 



network 




ACSE service defs 


8/3.5 


communication 


8/1 


support defs 


8/6 


DICOM communication 




support defs 


8/3.6 


network naming and addressing conventions 




8/3.2 


network presentation service defs 


8/3.4 


network reference model defs 


8/3.1 


network service conventions defs 


8/3.3 


NM equipment module 


3/C8.4.2 


NM image attribute descriptions 


3/C.8.4.3.1 


NM image IOD description (composite) 




3/A.5.1 


NM image IOD entity-relationship model 


(composite) 


3/A.5.2 


module table 


3/A.5.3 


module 


3/C.8.4.3 



NM series module 



3/C.8.4.1 



NM info object definition (composite) 3/A.5 



NM SPECT acquisition attribute descriptions 

3/C.8.4.4.1 
image module 3/C.8.4.4 

normalized and composite SOP classes 4/6.5.1 

normalized and composite SOP classes 3/6.5.1 

normalized objects IOD 3/6. 1 .2 

patient 3/B.l.l 

visit 3/B.2.1 

study 3/B.3.1 

study component 3/B .4. 1 

results 3/B.5.1 

interpretation 3/B .6. 1 

basic film session 3/B .7.1 

basic film box 3/B. 8.1 

basic image box 3/B .9. 1 
basic annotation presentation 3/B. 1 0. 1 

basic print job 3/B. 11.1 

basic printer 3/B. 12.1 

VOILUT 3/B.13.1 

image overlay box 3/B . 1 4. 1 

normative references 2/2 

notification, status codes, detached visit 
management SOP class 4/E.4.3.3 
detached interpretation management SOP 
class 4/G.4.3.3 

notification service class (normative), 
study content 4/D 

notification services (DIMSE-N) 7/7.5.2. 1 

notifications, detached patient management 
SOP class 4/E.3.3 
receive patient event, detached patient man 

agement SOP class 4/E.3.3. 1 

provide patient event, detached patient man 

agement SOP class 4/E.3.3.2 



notifications (continued) 

status codes, detached patient management 

SOP class 4/E.3.3. 
SCU conformance, detached patient 

management 4/E.3.5.1.2 
SCP conformance, detached patient 
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management 4/E.3.5.2.2 
detached visit management SOP class 

4/E.4.3 

receive visit event, detached visit management 
SOP class 4/E.4.3.1 

provide visit status event, detached visit 
management SOP class 4/E.4.3.2 

SCU conformance, requirements, detached 
visit management SOP class 4/E.4.5. 1 .2 

SCP conformance, requirements, detached 
visit management SOP class 4/E.4.5.2.2 

standard, SCU conformance, specialized SOP 
class conformance, patient management 
service class 4/E.6.3.2 

extended, SCU conformance, specialized SOP 
class conformance, patient management 
service class 4/E.6.3.3 

SCP conformance, specialized SOP class 
conformance, patient management service 
class 4/E.6.4.2 

detached study management SOP class 
4/F.3.3 

receive study event, detached study 
management SOP class 4/F.3.3. 1 

provide study event, detached study 
management SOP class 4/F.3.3.2 

status codes, detached study management SOP 
class 4/F.3.3.3 

SCU conformance, detached study 

management 4/F.3.5.1.2 

SCP conformance, detached study 

management 4/F.3.5.2. 

standard, SCU conformance, specialized SOP 
class conformance, study management 
service class 4/F.6.3.2 

extended, SCU conformance, specialized SOP 
class conformance, study management 
service class 4/F.6.3.3 

SCP conformance, specialized SOP class 
conformance, study management service 
class 4/F.6.4.2 

detached results management SOP class 
4/G.3.3 

receive results event, detached results 
management SOP class 4/G.3.3. 1 

provide results event, detached results 
management SOP class 4/G.3.3.2 



status codes, detached results management 
SOP class 4/G.3.3.3 

SCU conformance, detached results 

management 4/G.3.5.1.2 

SCP conformance, detached results 



management 4/G.3.5.2.2 
detached interpretation management SOP 

class 4/G.4.3 
receive interpretation event, detached 

interpretation management SOP class 
4/G.4.3.1 

provide interpretation status event, detached 
interpretation management SOP class 
4/G.4.3.2 

SCU conformance, requirements, detached 
interpretation management SOP class 

4/G.4.5.1.2 
SCP conformance, requirements, detached 
interpretation management SOP class 

4/G.4.5.2.2 

standard, SCU conformance, specialized SOP 
class conformance, patient management 
service class 4/G.6.3.2 

extended, SCU conformance, specialized SOP 
class conformance, patient management 
service class 4/G.6.3.3 

SCP conformance, specialized SOP class 
conformance, patient management service 
class 4/G.6.4.2 

nuclear medicine module (NM) 3/C.8.4 

number of completed sub-operations 7/9.1.3.1.8 

7/9.1.4.1.9 



number of failed sub-operations 



7/9.1.3.1.9 
7/9.1.4.1.10 



number of failed sub-operations 

(C-GET operation) 4/C.4.3.1.7 
(C-MOVE operation) 4/C.4.2.1.8 

number of frames/frame increment pointer 

3/C.7.6.6.1.1 

number of remaining sub-operations 7/9.1.3.1.7 

7/9.1.4.1.8 

(C-GET operation) 4/C.4.3.1.5 
(C-MOVE operation) 4/C.4.2.1.6 

number of successful sub-operations 

(C-GET operation) 4/C.4.3. 1 .6 

(C-MOVE operation) 4/C.4.2.1.7 

number of table break points 

(US) 3/C.8.5.2.1.7 

number of warning sub-operations 7.9. 1 3. 1 . 1 0 

7.9.1.4.1.1 

(C-GET operation) 4/C.4.3.1.8 
(C-MOVE operation) 4/CA2.1.9 
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OSI 



1/0.1,4 



on-line communication/media storage services 

3/6.3 
4/6.3 

operation services (DIMSE-C) 7/7.5. 1 . 1 
(DIMSE-N) 7/7.5.2.1 

operationMotification 7/A.4 

operations 

C-FIND 4/C.4.1 
C-MOVE 4/C.4.2 
C-GET 4/C.4.3 
detached patient management SOP class 

4/E.3.2 

SCU conformance, detached patient 

management 4/E.3 .5 . 1 . 1 

SCP conformance, detached patient 

management 4/E.3.5.2.1 

detached visit management SOP class 

4/E.4.2 

get visit information, detached visit 

management SOP class 4/E.4.2. 1 

set visit information, detached visit 

management SOP class 4/E.4.2.2 

SCU conformance, requirements, detached 
visit management SOP class 4/E.4.5. 1 

SCP conformance, requirements, detached 
visit management SOP class 4/E.4.5.2. 1 

SCU conformance, specialized SOP class 
conformance, patient management service 
class 4/E.6.3.1 

SCP conformance, specialized SOP class 
conformance, patient management service 
class 4/E.6.4.1 

detached study management SOP class 

4/F.3.2 

SCU conformance, detached study 

4/F.3.5.1.1 



operations, SCP conformance, detached study 
management 4/F.3.5.2.1 
study component management SOP class 
4/F.4.2 

SCU conformance, study component 

management 4/F.4.4.1.1 
SCP conformance, study component 

4/F.4.4.2.1 



SCU conformance, specialized SOP class 
conformance, study management service 
class 4/F.6.3.1 

SCP conformance, specialized SOP class 
conformance, study management service 
class 4/F.6.4.1 

detached results management SOP class 

4/G.3.2 

SCU conformance, detached results 

management 4/G.3.5.1.1 
SCP conformance, detached results 

management 4/G.3.5.2.1 
detached interpretation management SOP 

class 4/G.4.2 
get interpretation information, detached 

interpretation management SOP class 
4/G.4.2.1 

set interpretation information, detached 
interpretation management SOP class 
4/G.4.2.2 

SCU conformance, requirements, detached 
interpretation management SOP class 
4/G.4.5.1 

SCP conformance, requirements, detached 
interpretation management SOP class 

4/G.4.5.2.1 

SCU conformance, specialized SOP class 
conformance, patient management service 
class 4/G.6.3.1 

SCP conformance, specialized SOP class 
conformance, patient management service 
class 4/G.6.4.1 



optional keys 



4/C.2.2.1.3 



optional SOP classes, print management service 
class 4/H.3.3 

orientation, explanation of patient 3/E 

OSI layer/services concepts 8/G 

OSI network communication support 8/1 0. 1 . 1 

OSI upper layer profile 8/8 

OSI upper layer service 8/7 

overlay attribute descriptions 3/C.9.2. 1 

overlay coding/pixel data schemes 5/D 

overlay identification module 3/C.9. 1 

overlay IE 3/A. 1.2.7 
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overlay modules 
overlay plane, reference sequence 3 /C. 1 3. 10. 1 



overlay plane module 3/C.9.2 
overlay tape 3/C.9.2.1.1 

P 

PACS 1/4 

point-to-point environment 1 A). 1 

communication support 1/6.9 

p-data service 7/F 

P-data service 8/E 

P-DATA-RF pdu structure 8/9.3.5 

P-DATA -TF pdu structure 8/9.3.4 

palette color lookup table descriptor 

3/C.7.6.3.1.5 

parameters, C-STORE 7/9.1.1.1 
C-FIND 7/9.1.2.1 
C-GET 7/9.1.3.1 
C-MOVE 7/9.1.4.1 
C-ECHO 7/9.1.5.1 
(A-ABORT) 8/7.3.1 
(A-ASSOCIATE) 8/7.1.1 
(A-P-ABORT) 8/7.4.1 
(A-RELEASE) 8/7.2.1 

patient, create, patient management functional 
model 4/E.1.2.1 

patient, schedule visit, patient management 
functional model 4/E. 1 .2.2 



3/A. 1.2.1 

patient info object definition (normalized) 

3/B.l 

patient IOD description 3/B. 1 . 1 

modules 3/B. 1.2 

subset specification, get patient information 
4/E.3.2.1.1 

patient level, patient root SOP class group 

4/C.6.1.1.2 

patient level, patient/study only SOP class group 

4/C.6.3.1.2 

patient management functional model, create 
patient 4/E. 1.2.1 

patient management functional model, schedule 
visit 4/E. 1.2.2 

admit patient 4/E. 1.2.3 

transfer patient 4/E. 1 .2.4 

discharge patient 4/E. 1 .2.5 

4/E.1.2 
4/E.1.3 

service class (normative) 4/E 
states 4/E. 1.4 

patient medical module (normative) 3/C.2.4 

3/C.7.1.1 
3/C.2 

explanation of 3/E 

patient orientation 3/C.7.6. 1.1.1 

patient position 3/C.7.3. 1.1.2 

patient relationship module (normative) 3/C.2.1 

patient root query/retrieve info model 

4/C.3.1 



3/C.9 patient IE 



patient, admit, patient management functional patient root query/retrieve information model 
model 4/E.1.2.3 4/C.6.1.1 

SOP class group 4/C.6.1 

patient, transfer, patient management functional 

model 4/E. 1.2.4 patient study module (normative) 3/C.7.2.2 

patient, discharge, patient management functional patient summary module (norm ative)3/C. 7.7 
model 4/E.1.2.5 

patient type dir record keys def s 1 0/B.5. 1 

patient demographic module (normative) 

3/C.2.3 patient/study only query/retrieve info model 

4/C.3.3 

patient identification module (normative) 4/C.6.3 . 1 

3/C.2.2 SOP class group 4/C.6.3 
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patlette color lookup table data 3/C.7.6.3.1.6 presentation service definitions 2/3.3 



pdu structure (A-ASSOCIATE-AC) 8/9.3.2 
(A-ASSOCIATE-RJ) 8/9.3.3 
(A-ASSOCIATE-RQ) 8/9.3.1 
(P-DATA-TF) 8/9.3.4 



pending status class 



7/C.2 



perform study, study management functional 
model 4/F.1.2.4 

photometric interpretation 3/C.7.6.3. 1 .2 

(CT module) 3/C.8.2.1.1.3 

(MR image module) 3/C.8.3.1.1.3 

(US) 3/C.8.5.3.1.2 



physical media layer 



10/6.2.1 



physical units x direction (US) 3/C.8.5. 1 . 1 .2 

y direction (US) 3/C.8.5.1.1.2 

pixel component data type (US) 3/C.8.5.2.1.7 

mask (US) 3/C.8.5.2.1.5 

organization (US) 3/C.8.5.2.1.4 

physical units (US) 3/C.8.5.2. 1.6 



pixel data, encoding 

pixel data 

pixel data encoding 



5/8 

3/C.7.6.3.1.4 
5/8.1 



pixel data/overlay coding schemes 5/D 

pixel padding value (normative) 3/C.7.5. 1 . 1 .2 

pixel representation (US) 3/C.8.5.3.1.3 

pixels, image attributes 3/C.7.6.3.1 

planar configuration 3/C.7.6.3. 1 .3 

pointer, frame increment (NM) 3/C.8.4.3.1.1 

3/C.7.6.6.1.1 

(US) 3/C.8.5.3.1.4 

position reference indicator (normative) 

3/C.7.4.1.1.2 

Preformatted color image 3/C. 1 3.5.3 

grey scale image 3/C. 1 3.5.2 

prepare for study, study management functional 
model 4/F.1.2.3 

presentation protocol requirements (OSI upper 
layer) 8/8.3 



presentation service definitions 

(network) 8/3.4 

print job SOP class 4/H.4.5 

print management 

conformance 4/H.3 

data flow model 4/H.2. 1 

meta SOP classes 4/H.3.2 
model, print management service class 

4/H.2 

modules 3/C.13 

scu example 4.H.6 

service class (normative) 4/H 

service class structure 4/H.2.2 

SOP class definitions 4/H.4 

SOP classes 4/H.2.3 

print queue dir record keys defs 1 0/B.5.8 

printer module 3/C. 13.9 



printer SOP class 
priority 



(C-FIND operation) 
(C-GET operation) 
(C-MOVE operation) 



4/H.4.6 

7/9.1.3.1.4 
7/9.1.4.1.4 
7/9.1.1.1.5 
4/C.4.1.1.2 
4/C.4.3.1.2 
4/C.4.2.1.2 



protocol 7/10.3 
(ACSE requirements; OSI upper layer) 

8/8.2 

(association) 7/8.2 
(C-STORE) 7/9.3 
(C-STORE) 7/9.3.1.3 
(DIMSE) 7/8.1 
(presentation requirements; OSI upper 
layer) 8/8.3 
(session requirements; OSI upper layer) 

8/8.4 

(upper layer for state machine) 8/9.2 
(upper layer for TCP/IP data units struct) 

8/9.3 

protocol (continued) 

(upper layer for TCP/IP) 8/9 
overview 7/8 

protocols, N-EVENT-REPORT 7/10.3.1 
N-GET 7/10.3.2 
N-SET 7/10.3.3 



A-24 



©1993 Kodak Health Imaging Systems, Inc. 



Appendix A: DICOM 3.0 Specification Index 



N-ACTION 
N-CREATE 
N-DELETE 



7/10.3.4 
7/10.3.5 
7/10.3.6 



provide interpretation status event notifications, 
detached interpretation management SOP class 

4/G.4.3.2 

provide patient event notification, detached 
patient management SOP class 4/E.3 .3 .2 

provide results event notification, detached 
results management SOP class 4/G.3.3.2 



provide study event notification, detached study 
management SOP class 4/F.3.3.2 

provide visit status event notifications, detached 
visit management SOP class 4/E.4.3.2 



q-r 



receive study event notification, detached study 
management SOP class 4/F.3.3. 1 

receive visit event notification, detached visit 
management SOP class 4/E.4.3. 1 

record amendment, results management function- 
al model 4/G. 1.2.5 

record results, results management functional 
model 4/G. 1.2.2 

2/3/1 
3/3.1 
8/3.1 



reference model 
definitions 
(network) 



reference overlay plane sequence 3/C. 1 3. 10. 1 



reference pixel xO (US) 
y0(US) 



3/C.8.5.1.1.3 
3/C.8.5.1.1.3 



referenced color print management meta SOP 
class 4/H.3.2.2.4 
grayscale print management meta SOP class 

4/H.3.2.2.3 
image box SOP class 4/H.4.3.3 



references, normative 
RIS 



1/2 
1/4 



queries, relational of extended behavior of 
SCU(C-FIND) 4/C.4. 1.2.2.1 

SCP(C-FIND) 4/C.4. 1.3.11 

query/retrieve information model definition 

4/C.2,C3 

query/retrieve service class 4/C 

range matching 4/C.2.2.2.5 

read the study, study management functional 
model 4/F.1.2.6 



real-world entity 



2/5.1.2 



region 

data type (US) 
flags (US) 

location max xl (US) 
location max yl (US) 
location min xO (US) 
location min yO (US) 
spatial format (US) 



receive interpretation event notification, detached 
interpretation management SOP class 4/G .4.3.1 

receive patient event notification, detached pa- 
tient management SOP class 4/E.3.3.1 

receive results event notification, detached results 
management SOP class 4/G.3.3. 1 



3/C.8.5.2.1.2 
3/C.8.5.2.1.3 
3/C.8.5.1.1.1 
3/C.8.5.1.1.1 
3/C.8.5.1.1.1 
3/C.8.5.1.1.1 
3/C.8.5.2.1.1 



relational retrieve (C-GET, SCU)4/C.4.3. 2.2.1 
(C-GET,SCP) 4/C.4.3.3.2.1 
(C-MOVE, SCU) 4/C.4.2.2.2. 1 

(C-MOVE, SCP) 4/C.4.2.3.2. 1 

relational search method, extended behavior of 
SCP (C-FIND) 4/C.4. 1.3.2.2 

(C-FIND) 4/C.4.1.3.2.2 

relational-queries, extended behavior of 
SCU (C-FIND) 4/C.4.1.2.2.1 
SCP (C-FIND) 4/C.4.1.3.2.1 

relationship (service classes) 4/5. 1 .2 



request identifier structure 
(C-GET operation) 
(C-MOVE operation) 



4/C.4.1.1.3.1 
4/C.4.3. 1.3.1 
4/C.4.2.1A1 



requested SOP class UID (N-ACTION) 

7/10.1.4.1.3 
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(N-DELETE) 

(N-GET) 

(N-SET) 

requested SOP instance UID 
(N-ACTION) 
(N-DELETE) 
(N-GET) 
(N-SET) 

required keys 



7/10.1.6.1.3 
7/10.1.2.1.3 
7/10.1.3.1.3 



7/10.1.4.1.4 
7/10.1.6.1.4 
7/10.1.2.1.4 
7/10.1.3.1.4 

4/C.2.2.1.2 



results management functional model 



requirements, conformance, patient root SOP 
class group 4/C.6. 1 .2 

study root SOP class group 4/C.6.2.2 

requirements, conformance, patient/study only 
SOP class group 4/C.6.3.2 



reserved identifications 



4/H.4.6.5 



response identifier structure 4/C.4. 1 . 1 .3 .2 
(C-GET operation) 4/C.4.3.1.3.2 
(C-MOVE operation) 4/C.4.2. 1.4.2 

response status values (service classes) 4/5.3 

responses, multiple (DIMSE) 7/7.5.3.2 

results, create, results management functional 
model 4/G.1.2.1 

results, 

record, results management functional 
model 4/G. 1.2.2 

transcribe for, results management functional 
model 4/G.1.2.3 

approve, results management functional 
model 4/G. 1.2.4 



results dir record keys def s 



10/B.5.7 



results identification module (normative) 

3/C.5.2 

results impressions module (normative) 

3/C.5.3 

results info object definition (normalized) 

3/B.5 

results IOD description 3/B.5. 1 

modules 3/B.5.2 

results IOD subset specification, get results 
information 4/G.3.2.1.1 



create results 


4/G. 1.2.1 


record results 


4/G. 1.2.2 


transcribe results for 


4/G. 1.2.3 


approve results 


4/G. 1.2.4 


record amendment 


4/G. 1.2.5 


transcribe amendment 


4/G. 1.2.6 


approve amendment 


4/G.1.2.7 




4/G. 1.2 




4/G. 1.3 



results management service class (normative) 

4/G 

results management states 4/G. 1.4 

results modules (normative) 3/C.5 

results relationship module (normative) 

3/C.5.1 



retrieve, relational 
(C-MOVE, SCU) 
(C-MOVE, SCP) 
(C-GET, SCU) 
(C-GET, SCP) 



4/C.4.2.2.2.1 
4/C.4.2.3.2.1 
4/C.4.3.2.2.1 
4/C.4.3.3.2.1 



ROI area, mean, and standard deviation 

3/C.9.2.1.2 

row symmetric image display format 

3/C.13.3.1.2 



semantics 

service class specifications 

symbols and abbreviations 

samples per pixel 
(CT module) 
(MR image module) 

SC equipment module 

SC image IOD 

description (composite) 



1/6.5 
1/6.4 
1/4 

3/C.7.6.3.1.1 
3/C.8.2.1.1.2 
3/C.8.3.1.1.2 

3/C.8.6.1 
3/A.8.1 



entity-relationship model (composite) 
3/A.8.2 

module table 3/A.8.3 
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SC image module 



3/C.8.6.2 



SC info object definition (composite) 
3/A.8 

schedule study, study management functional 
model 4/F.1.2.2 

schedule visit, patient management functional 
model 4/E.1.2.2 

scope of GET command, patient root SOP class 
group 4/C.6. 1.1.6 

study root SOP class group 4/C.6.2. 1.5 
patient/study only SOP class group 

4/C.6.3.1.4 

scope of PUT command, patient root SOP class 
group 4/C.6. 1.1.6 

study root SOP class group 4/C.6.2. 1 .5 
patient/study only SOP class group 

4/C.6.3.1.4 

SCP, behavior of 4/B.2.2 
conformance statement 4/B.4.3.2 
baseline behavior (C-FIND) 4/C.4.1.3.1 
extended behavior (C-FIND) 4/C.4.1.3.2 
baseline behavior (C-MOVE) 4/C.4.2.3.1 
extended behavior (C-MOVE)4/C.4.2.3.2 
baseline behavior (C-GET) 4/C.4.3.3. 1 
extended behavior (C-GET) 4/C.4.3.3.2 

SCP behavior (C-FIND) 4/C.4. 1.3 

(C-GET) 4/C.4.3.3 
(C-MOVE) 4/C.4.2.3 

SCP conformance, C-FIND 4/C.6. 1.2.2. 1 

patient root SOP class group 4/C.6. 1 .2.2. 1 

C-MOVE 4/C.6. 1.2.2. 

patient root SOP class group 4/C.6. 1 .2.2.2 

C-GET 4/C.6. 1.2.2.3 

C-GET , patient root SOP class group 

4/C.6. 1.2.2.3 

C-FIND 4/C.6.2.2.2.1 
C-FIND, study root SOP class group 

4/C.6.2.2.2.1 

C-MOVE 4/C.6.2.2.2.2 
C-MOVE , study root SOP class group 

4/C.6.2.2.2.2 

C-GET 4/C.6.2.2.2.3 
C-GET , study root SOP class group 

4/C.6.2.2.2.3 

C-FIND 4/C.6.3.2.2.1 
C-FIND, patient/study only SOP class group 
4/C.6.3.2.2.1 



C-MOVE 4/C.6.3.2.2.2 
C-MOVE , patient/study only SOP class 

group 4/C.6.3.2.2.2 
C-GET 4/C.6.3.2.2.3 
C-GET , patient/study only SOP class group 
4/C.6.3.2.2.3 
SCP conformance, detached patient management 
4/E.3.5.2 

requirements, detached visit management 

SOP class 4/E.4.5.2 
specialized SOP class conformance, patient 

management service class 4/E.6.4 
detached study management 4/F.3.5.2 
study component management 4/F.4.4.2 
specialized SOP class conformance, study 

management service class 4/F.6.4 
detached results management 4/G.3.5.2 
requirements, detached interpretation 

management SOP class 4/G.4.5.2 
specialized SOP class conformance, patient 

management service class 4/G.6.4 



SCP conformance 



4/C.6.1.2.2 
4/C.6.2.2.2 
4/C.6.3.2.2 



SCP conformance requirements, study content 
notification service class 4/D.4.4.2 



SCU, behavior of 



4/B.2.1 



SCU, conformance statement 4/B .4.3.1 
SCU 

baseline behavior (C-FIND) 4/C.4.1.2.1 
extended behavior (C-FIND) 4/C.4. 1 .2.2 
baseline behavior (C-MOVE) 4/C.4.2.2.1 
extended behavior (C-MOVE)4/C.4.2.2.2 

SCU(continued) 

baseline behavior (C-GET) 4/C.4.3.2.1 

extended behavior (C-GET) 4/C.4.3.2.2 

(C-FIND) 4/C.4.1.2 

(C-GET) 4/C.4.3.2 

(C-MOVE) 4/C.4.2.2 

SCU conformance, C-FIND 4/C.6.1.2.1.1 
patient root SOP class group 4/C.6. 1 .2. 1 . 1 
C-MOVE 4/C.6.1.2.1.2 



C-MOVE, patient root SOP class group 

4/C.6.1.2.1.2 

C-GET 4/C.6.1.2.1.3 
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C-GET, patient root SOP class group 

4/C.6.1.2.1.3 

C-FIND 4/C.6.2.2.1.1 
C-FIND, study root SOP class group 

4/C.6.2.2.1.1 

C-MOVE 4/C.6.2.2.1.2 
C-MOVE, study root SOP class group 

4/C.6.2.2.1.2 

C-GET 4/C.6.2.2.1.3 
C-GET, study root SOP class group 

4/C.6.2.2.1.3 

C-FIND 4/C.6.3.2.U 
C-FIND, patient/study only SOP class group 
4/C.6.3.2.1.1 

C-MOVE 4/C6.3.2.1.2 
C-MOVE, patient/study only SOP class 

group 4/C.6.3.2.1.2 
C-GET 4/C.6.3.2.1.3 
C-GET, patient/study only SOP class group 
4/C.6.3.2.1.3 

SCU conformance, requirements, 

detached patient management 4/E.3.5.1 
detached visit management SOP class 
4/E.4.5 

SCU conformance, specialized SOP class 
conformance, patient management service 
class 4/E.6.3 

SCU conformance, requirements, detached study 
management 4/F.3.5.1 

SCU conformance, requirements, study 
component management 4/F.4.4.1 

SCU conformance, specialized SOP class 
conformance, study management service 
class 4/F.6.3 

SCU conformance, requirements, detached results 

4/G.3.5.1 



SCU conformance, requirements, detached 
interpretation management SOP class 
4/G.4.5 

SCU conformance, specialized SOP class 
conformance, patient management service 
class 4/G.6.3 



SCU conformance 



4/C.6.1.2.1 
4/C.6.2.2.1 
4/C.6.3.2.1 



notification service class 4/D.4.4. 1 

SCU/SCP behavior (normative) 4/A.2 

search method, hierarchical 4/C.4. 1.3.1.1 

search method, relational extended behavior of 
SCP (C-FIND) 4/C.4. 1.3.2.2 



secondary capture (SC) modules 3/C.8.6 


sending AE title 


7/9.1.1.1.6 


sequence, delimitation of 


5/7.5.2 


sequence matching 


4/C.2.2.2.6 


sequences (service classes) 


4/5.2 


sequencing 


7/10.2 




7/9.2 


series dir record keys defs 


10/B.5.3 


series IE 


3/A.L2.3 



SCU conformance requirements, study content 



series level, patient root SOP class group 

4/C.6.1.1.4 

series level, study root SOP class group 

4/C.6.2.1.3 

service class, 

study content notification (normative)4/D 
patient management (normative) 4/E 
study management (normative) 4/F 
results management (normative) 4/G 
print management (normative) 4/H 
print management, structure of 4/H. 2. 2 

service class application information 

(A-ASSOCIATE-AC) 4/B.3.1.2 

service class (continued) 

application information (A-ASSOCIATE- 
RQ) 4/B.3.1.1 
negotiation 8/D.2 

service class provider, 

get patient information 4/E . 3 .2. 1 .3 

get visit information 4/E.4.2. 1 .3 

set visit information 4/E.4.2.2.3 

get study information 4/F. 3. 2. 1 .3 

set study information 4/F.3.2.2.3 
create study component instance 4/F.4.2.1.3 

set study information 4/F.4.2.2.3 
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get study component information 4/F.4.2.3.3 


service/object pair (SOP) class 


4/6.5 


get results information 


4/G.3.2.1.3 






get interpretation information 


4/G.4.2.1.3 


services 




set interpretation information 


4/G.4.2.2.3 


on-line communication and media storage 


study content notification 


4/D.4.1 




3/6.3 




DIMSE-C 


3/6.3.1 


service class specification 


3/6.7 


DIMSE-N 


3/6.3.2 




4/6.7 


online communication and media storage 








4/6.3 


service class user 




DIMSE-C 


4/6.3.1 


study content notification 


4/D.4.2 


DIMSE-N 


4/6.3.2 


get patient information 


4/E.3.2.1.2 


p-data 


8/E 


get visit information 


4/E.4.2.1.2 


DIMSE-N 


7/10 


set visit information 


4/E.4.2.2.2 




7/1 ft 1 1 
//1U.1.1 


get study information 


4/F.3.2.1.2 


N-GET 


7/10.1.2 


set study information 


4/F.3.2.2.2 


N-SET 


7/10.1.3 


create study component instance 4/F.4.2.1.2 


XT A /TT/^lVT 

N-AC HON 


inn i a 
//1U.1.4 


set study information 


4/F.4.2.2.2 


vt mriTP 

N-CREATE 


7/10.1.5 


get study component information 4/F.4.2.3.2 


N-DELETE 


7/10.1.6 


get results information 


4/G.3.2.1.2 


types of 


7/10.2.1 


get interpretation information 


4/G.4.2.1.2 


(A-ABORT) 


8/7.3. 7.3.2 


set interpretation information 


4/G.4.2.2.2 


(A -ASSOCIATE) 


8/7.1,7.1.2 






(A-P-ABORT) 


8/7.4,7.4. 


service classes 


4/5 


(A-RELEASE) 


8/7.2,7.2.2 


conventions 


(C-ECHO) 


7/9.1.5 


(query/retrieve) 


4/C 


(C-FIND) 


7/9.1.2 


(verification)(normative) 


4/A 


(C-GET) 


7/9.1.3 


service context 


7/6 


(C-MOVE) 


7/9.1.4 


(C-STORE) 


7/9.1.1 


service conventions definition 




(DIMSE) 


7/7.5 


(network) 


8/3.3 


(DIMSE-Q 


7/7.5.1 




(DIMSE-Q 


7/9.1 


service conventions definitions 


3/3.2 


(DIMSE-N) 


7/10 






(DIMSE-N) 


7/7.5.2 


service definition (normative) 


4/B 






(query/retrieve) 


4/C.1.4 


session protocol requirements (OSI upper layer) 








8/8.4 


service groups (DIMSE-C) 


4/C4 






service modes 


7/7.3 


set interpretation information, operations, de- 


tached interpretation management SOP class 








4/G.4.2.2 


service parameters 








(C-FIND) 


4/C.4.1.1 


set study information, operations, detached study 


(C-GET) 


4/C.4.3.1 


mangement SOP class 


4/F.3.2.2 


(C-MOVE) 


4/C.4.2.1 








set study information, operations, study 


service procedures 




component mangement SOP class 4/F.4.2.2 


(C-FIND) 


7/9.1.2.2 






(C-GET) 


7/9.1.3.2 


set visit information, operations, detached visit 


(C-MOVE) 


7/9.1.4.2 


management SOP class 


4/E.4.2.2 


service types 


7/7.1 


single value matching 


4/C.2.2.2.1 


service-object pair class ID 


7/D.l.l 


slice location 


3/C.7.6.2.1.2 






soft tissue thermal index (US) 


3/C.8.5.3.1.8 
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SOP class 



SOP class definition and UID 



3/6.5 



(DIMSE, film session) 


4/H.4.1.2 


(DIMSE, film box) 


4/H.4.2.3 


(DIMSE, film box) 


4/H.4.3.1.3 


(DIMSE, film box) 


4/H.4.3.2.3 


(DIMSE, film box) 


4/H.4.3.3.3 


(DIMSE, film box) 


4/H.4.4.3 


(DIMSE, print job) 


4/H.4.5.4 


(DIMSE, printer) 


4/H.4.6.3 


(DIMSE, VOILUT) 


4/H.4.7.3 


(DIMSE, image overlay box) 


4/H.4.8.3 



SOP class definitions 



4/C.6 



SOP class group, patient root 4/C.6. 1 

SOP class group, study root 4/C.6.2 

SOP class group, patient/study only 

4/G6.3 

SOP class identification, specialized 

4/B.4.4.1 



SOP class UID 



3/C.12.1.1.1 



SOP class UID (basic study content notification) 

4/D.4.3 

(C-FIND operation) C/4.1.1.1 
(C-GET operation) 4/0.4.3.1.1 
(C-MOVE operation) 4/C.4.2.1.1 



SOP class UIDs index 



4/H 



SOP classes, rales for types 2/7. 1 
normalized and composite 4/6.5.1 
standard 4/B.4.5 
association negotiation for C-FIND 
4/C.5.1 



SOP classes 

extended negotiations 



4/C.5.1.1 



SOP classes, C-FIND, extended negotiation for 

sub-item structure 

(A-ASSOCIATE-RQ) 4/C.5. 1.1.1 

(A-ASSOCIATE-AQ 4/C.5. 1. 1.2 

SOP classes, assocation negotiation for 
C-MOVE 4/C.5.2 

SOP classes, extended negotiations (C-MOVE) 

4/C5.2.1 

SOP classes, C-MOVE, extended negotiation for 



sub-item structure 

(A-ASSOCIATE-RQ) 4/C.5.2. 1. 1 

(A-ASSOCIATE-AQ 4/C.5.2. 1.2 

SOP classes 

associatio negotiation for SOP C-GET 

4/C.5.3 

extended negotiations (C-GET) 4/C.5.3.1 
patient root group 4/C.6.1.3 
study root group 4/C.6.2.3 
patient/study only group 4/C.6.3.3 
study content notification 4/D.4 
detached patient management 4/E.3 
detached patient management UID 4/E.3.4 
detached visit management 4/E.4 
detached visit management UID 4/E.4.4 
meta, detached patient management 4/E.5 
meta, detached patient management UID 

4/E.5.1 

specialized, conformance 4/E.6 
detached study management 4/F.3 
detached study management UID 4/F.3.4 
study component management 4/F.4 
study component management UID 4/F.3.4 
meta, study management 4/F.5 
meta, study management UID 4/F.5. 1 
study management service class, specialized, 

conformance 4/F.6 
detached results management 4/G.3 
detached results management UID 4/G.3.4 
detached interpretation management 4/G.4 
detached interpretation management UID 

4/G.4.4 

meta, detached patient management 4/G.5 
meta, detached patient management UID 

4/G.5.1 

specialized, conformance 4/G.6 
print management 4/H. 2. 3 

meta, print management 4/H. 3.2 

SOP classes (continued) 

meta, basic grayscale print management 

4/H.3.2.2.1 

meta, basic color print management 

4/H.3.2.2.2 

meta, referenced grayscale print management 

4/H.3.2.2.3 

meta, referenced color print management 

4/H.3.2.2.4 

optional, print management service class 

4/H.3.3 



SOP classes 



4/C.6.1.3 
4/C.6.2.3 
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4/C.6.3.3 

SOP classes (verification) 4/A.4 

SOP common attribute descriptions 3/C . 12.1. 1 

SOP common module 3/C.12. 1 

SOP instance UID 3/C12.1.1.1 

source image sequence 3/C.7.6. 1 . 1 .4 

specialized SOP class conformance, study 
management service class 4/F.6 

specialized SOP class conformance 4/E.6 

4/G.6 

specialized SOP class identification, study 
management service class 4/F.6.2 

specialized SOP class identification 4/E.6.2 

4/G.6.2 



specific character set 



3/C.12.1.1.2 



standalone curve image IOD description 
(composite) 3/A.10.1 
entity-relationship model (composite) 

3/A.10.2 

module table 3/A.10.3 

standalone curve info object definition 
(composite) 3/A. 10 

standalone modality LUT image IOD 

description (composite) 3/A. 12.1 

entity-relationship model (composite) 

3/A. 12.2 

module table 3/A. 12.3 



standalone modality LUT info object definition 
(composite) 3/A. 12 

standalone overlay image IOD 

description (composite) 3/A.9.1 
entity-relationship model (composite) 

3/A.9.2 

module table 3/A.9.3 

standalone overlay info object definition 
(composite) 3/A.9 

standalone VOI LUT image IOD description 



(composite) 3/A. 13.1 

entity-relationship model (composite) 
3/A. 13.2 

module table 3/A. 13.3 

standalone VOI LUT info object definition 
(composite) 3/A. 13 

standard notification, SCU conformance, special- 
ized SOP class conformance, patient management 
service class 4/E.6.3.2 

standard notification, SCU conformance, special- 
ized SOP class conformance, study management 
service class 4/F.6.3.2 

standard notification, SCU conformance, special- 
ized SOP class conformance, patient management 
service class 4/G.6.3.2 



state machine actions defs 

states, patient management 
study management 
results management 

status 



status 

(C-FIND operation) 
(C-GET operation) 
(C-MOVE operation) 
(N-ACTION) 
(N-CREATE) 
(N-EVENT-REPORT) 
(N-GET) 
(N-SET) 

status class, 
success 
pending 



warning 
failure 



8/9.2.2 

4/E.1.4 
4/F.1.4 
4/G.1.4 

7/9.1.2.1.5 
7/9.1.3.1.6 
7/9.1.4.1.7 
7/9.1.1.1.9 
7/9.1.5.1.4 



4/C.4. 1.1.4 

4/C.4.3.1.4 

4/C.4.2.1.5 

7/10.1.4.1.10 

7/10.1.5.1.6 

7/10.1.1.1.8 

7/10.1.2.1.9 

7/10.1.3.1.9 



7/C.l 
7/C.2 
7/C.3 
7/C.4 
7/C.5 



status codes 

get patient information 4/E.3 .2. 1 .4 

detached patient management SOP class 
4/EJ.3.3 

get visit information 4/E.4.2. 1 .4 

set visit information 4/E.4.2.2.4 
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notification, detached visit management SOP 

class 4/E.4.3.3 
get study infoimation 4/F.3.2. 1 .4 

set study information 4/F.3.2.2.4 
detached study management SOP class 

4/F.3.3.3 

create stody component instance 4/F.4.2.1.4 
set study information 4/F.4.2.2.4 
get study component information 4/F.4.2.3.4 
get results information 4/G.3.2. 1 .4 

detached results management SOP class 

4/G.3.3.3 

get interpretation infoimation 4/G.4.2. 1 .4 
set interpretation infoimation 4/G.4.2.2.4 
notification, detached interpretation 

management SOP class 4/G.4.3.3 



status type encoding 
statuses 



7/C 
4/B.2.3 



staus (N-DELETE) 7/10.1.6.1.7 

storage service class (normative) 4/B 

study, create, study management functional 
model 4/F.1.2.1 

study, schedule, study management functional 
model 4/F.1.2.2 

study, prepare, study management functional 
model 4/F.1.2.3 

study, perform, study management functional 
model 4/F.1.2.4 

study, verify quality of, study management func- 
tional model 4/F. 1.2.5 

study, read, study management functional model 

4/F.1.2.6 

study acquisition module (normative) 3/C.4.5 

study component info object definition 
(normalized) 3/B.4 

study component IOD 

description 3/B.4.1 
modules 3/B.4.2 
subset specification, create study component 

instance 4/F.4.2.1.1 
subset specification, get study component 

information 4^.4.2.3.1 



study component management SOP class UID 

4/F.3.4 

study component module (normative) 3/C.4.7 

study component relationship module 
(normative) 3/C.4.8 

study component status module (normative) 

3/C.4.9 

study content module (normative) 3/C.7.8 

study content notification service class 
(normative) 4/D 

study identification module (normative) 3/C.4.2 

study IE 3/A.1.2.2 

study info object definition (normalized) 3/B.3 

study IOD description 3/B.3.1 

study IOD modules 3/B.3.2 

study IOD subset specification, get study 
information 4/F.3.2.1.1 

study IOD subset specification, set study 
information 4/R3.2.2.1 

study IOD subset specification, set study 
information 4/F.4.2.2.1 

study level 

patient root SOP class group 4/C.6. 1.1.3 
study root SOP class group 4/C.6.2.1.2 
patient/study only SOP class group 

4/C.6.3.1.3 

study management functional model, create 
study 4/F.1.2.1 

study management functional model 

schedule study 4/F. 1 .2.2 

prepare for stody 4/F. 1 .2.3 

perform study 4/F. 1.2.4 

verify study quality 4/F. 1 .2.5 

read the study 4/F. 1 .2.6 

study management functional model 4/F. 1.2 
informational model 4/F. 1 .3 

study management meta SOP class 4/F.5 
UID 4/F.5.1 



study component management SOP class 4/F.4 
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study management service class (normative) 

4/F 

study management states 4/F. 1 .4 

study module (normative) 3/C.4.3 

study modules (normative) 3/C.4 

study read module (normative) 3/C.4.6 

study relationship module (normative) 3 /C.4. 1 

study root query/retrieve info model 4/C.3.2 

study root query/retrieve information model 

4/C.6.2.1 

study root SOP class group4/C.6.2 

study scheduling module (normative) 3/C.4.4 

study type ctir record keys defs 10/B.5.2 

sub-operations 

number of remaining (C-MOVE operation) 

4/C.4.2.1.6 
number of successful (C-MOVE operation) 

4/C.4.2.1.7 
number of failed (C-MOVE operation) 

4/C.4.2.1.8 
number of warning (C-MOVE operation) 

4/C.4.2.1.9 
number of remaining (C-GET operation) 

4/C.4.3.1.5 
number of successful (C-GET operation) 

4/C.4.3.1.6 
number of failed (C-GET operation) 

4/C.4.3.1.7 
number of warning (C-GET operation) 

4/C.4.3.1.8 

patient root SOP class group 4/C.6. 1 . 1 .6 
study root SOP class group 4/C.6.2. 1 .5 



syntax (transfer specifications: normative) 5/A 

syntax (transfer) 5/10 

syntaxes, abstract and transfer 

encoding 8/B.3.1 
(private) 8/B.3.2 

syntaxes, transfer syntaxes, and service class 
UIDs 8/F 



syntaxes 
transfer 
abstract 
(abstract) 
(transfer) 



7/D.2 
7/D.l 
8/B.l 
8/B.2 



TCP/IP 1/0.1,4 
TCP (transport service provide) 8/9. 1 
TCP transport connection, opening 8/9. 1 . 1 

TCP transport connection, transferring data 

8/9.1.2 

TCP transport connection, closing 8/9. 1 .4 

TCP/IP (protocol for upper layer) 8/9 

TCP/IP (upper layer protocol for data units 
structure) 8/9.3 

TCP/IP communication support 8/10.1.2 

TCP/IP state machine, upper layer protocol 

8/9.2 

TCP/IP state transition table 8/9.2.3 



sub-operations, patient/study only SOP class 
group 4/C.6.3.1.4 


time of last calibration (normative) 

3/C.7.5.1.1.1 


sub-operations (DIMSE) 


7/7.5.3.1 


timer, ARTIM 


8/9.1.5 


success status class 


7/C.l 


TM-line position X0 (US) 


3/C.8.5.2.1.10 


support of character repertoires 


5/6.1 


TM-line position Y0 (US) 


3/C.8.5.2.1.11 


symbols and abbreviations 


2/4 


topic dir record keys defs 


10/B.5.5 


synchronization, audio 


3/C.10.3.1 


transcribe amendment, results management 






functional model 


4/G. 1.2.6 
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transcribe for results, results management 



functional model 4/G. 1.2.3 

transducer orientation (US) 3/C.8.5.3. 1 .6 

transducer position (US) 3/C.8.5.3. 1 .5 

transfer patient, patient management functional 

model 4/E.1.2.4 

transfer syntax 

default 5/10.1 

for lossless JPEG 5/10.2 

for lossy JPEG 5/10.3 

UIDs index 5/H 

transfer syntax 5/10 

(encapsulation of encoded pix. data) 5/A.4 

specifications (normative) 5/A 

transfer syntaxes 7/D.2 

(network) 8/B.2 

transport connection 

opening for TCP 8/9.1.1 

transferring data on TCP 8/9.1.3 

closing for TCP 8/9.1.4 

transport service (provided by TCP) 8/9.1 

type designation (norm all zed) 3/C. 1 .2.3 

type of data (curve attributes) 3/C.10.2. 1. 1 

types of services 7/10.2.1 



types of services (sequencing) 7/9.2.1 



u 



UID, creating a private 5/B 

UID encoding rules 5/9.1 

UID matching, list 4/C.2.2.2.2 

UID registration 5/9.2 

UID registration process 5/C 
UIDs, 

defined and registered 5/9.2.1 



privately defined 



tranfer syntax index 


5/H 


registry of DICOM unique 


6/A 


service class 


8/F 


UIDs 


5/9 


UL encoding rules 


8/F 


ultrasound modules (US) 


3/C.8.5 


unique keys 


4/C.2.2.U 


universal matching 


4/C.2.2.2.3 


US frame of reference attribute definitions 




3/C.8.5.1.1 


US frame of reference module 


3/C.8.5.1 


US image attribute descriptions 


3/C.8.5.3.1 



US image IOD description (composite) 3/A.6.1 

US image IOD entity-relationship model 
(composite) 3/A.6.2 

US image IOD module table 3/A.6.3 

US image module 3/C.8.5.3 

US info object definition (composite) 3/A.6 

US multi-frame image IOD 

description (composite) 3/A.7.1 
entity-relationship model (composite) 

3/A.7.2 

module table 3/A.7.3 

US multi-frame info object definition 
(composite) 3/A.7 

US region calibration attribute definitions 

3/C.8.5.2.1 

US region calibration module 3/C.8.5.2 

usage restrictions 7/10.2.2 

usage restrictions (sequencing) 7/9.2.2 

usage specification, print management service 
class 4/H.2.4 

usage specification (service classes) 4/5.4 

user option modules, composite 3/A. 1.3.3 
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3/C.l 1.2.1.1 
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VOI LUT IOD description 3/B.13.1 

VOI LUT IOD modules 3/B.13.2 

VOI LUT module 3/C.l 1.2 

VOI LUT SOP class 4/H.4.7 

warning status class 7/C.4 

value encoding 5/6 wild card matching 4/C.2.2.2.4 

value matching 4/C.2.2.2. 1 window c^/width (VOI LUT) 

value representation 5/6.2 

values, matching multiple 4/C.2.2.3 

values, enumerated 5/6.3 

values, multiplicity and delimitation 5/6.4 

verification service class (normative) 4/A 

verification SOP class (normative) 4/A.4 

verify study quality, study management 
functional model 4/F. 1.2.5 

visit admission module (normative) 3/C.3.4 

visit dir record keys def s 1 0/B.5.6 

visit discharge module (normative) 3/C.3.5 

visit identification module (normative) 3/C.3.2 

visit info object definition (normalized) 3/B.2 

visit IOD description 3/B.2. 1 

visit IOD modules 3/B.2.2 

visit IOD subset specification, get visit 
information 4/E.4.2.1.1 

visit IOD subset specification, set visit 
information 4/E.4.2.2.1 

visit modules (normative) 3/C.3 

visit relationship module (normative) 3/C.3. 1 

visit scheduling module (normative) 3/C.3.6 

visit status module (normative) 3/C.3.3 

VOI LUT info object definition (normalized) 

3/B.13 
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a-b 



abstract syntax 



ACR-NEMA 



Same as the SOP (service/object pair) class. A combination 
of the service class and the type of information object upon 
which it should operate. 



American College of Radiology 
Manufacturers Association 



National Electrical 



application Associated with that transport connection is an application 

context context There is a single application context that is used 

for all DICOM communication - the DICOM 3.0 applica- 
tion context 

application Can be a program or can be just a piece of a program, or can 

entity be a whole group of programs that cooperate with one 

another. In an abstract sense, though, it can be viewed 
across the network as a single, collective entity. 



association 



Context for communication 



association 
control service 
element 



ACSE; the type of service element you use to set up an 
association. 



attribute 



A property of an Information Object. It has a name and a 
value which are independent of any encoding scheme. 



c-d 

command A DICOM command is a generic means to operate on 

Information Objects across an interface or network. 

command An encoding of a parameter of a command which conveys 

element this parameter's value. 

command The result of encoding a set of DICOM command elements 

stream using the DICOM encoding scheme. 
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composite 



conformance 
statement 



data dictionary 

data element 
data set 



data stream 

DICOM 
DIMSE 



A type of information object that contains multiple 
attributes, as opposed to normalized objects that contain 
one attribute only. 

A formal statement associated with a specific implementa- 
tion of the DICOM standard. It specifies the service 
classes, information objects, and communication protocols 
supported by the implementation. 

A registry of DICOM data elements which assigns a unique 
tag, a name, value characteristics, and semantics to each 
data element 

A unit of information as defined by a single entry in the 
data dictionary. 

Exchanged information consisting of a structured set of 
attribute values directly or indirectly related to information 
objects. The value of each attribute in a data set is 
expressed as a data element. 

The result of encoding a data set using the DICOM 
encoding scheme (data element numbers and representa- 
tions as specified by the data dictionary). 

Digital Imaging and Communications in Medicine 

DICOM Message Service Element 



e-g 



element types 



1 = required 

1C = required if a condition is met 

2 = primary diagnostic; required 

2C = primary diagnostic; required if a condition is met 

3 = optional 



film box One file; one member of a film session. 

film session A group of films. (Each film is a "film box," so this is a 

group of film boxes.) 
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h-l 

information An abstraction of a real information entity (e.g., CT, Study, 

objects etc.), which is acted upon by one or more DICOM 

commands. 

information A formal description of an information object which 

object class includes a description of its purpose and the attributes it 
posses. It does not include values for these attributes. 



information 

object 

instance 



A representation of an occurrence of a real-world entity, 
which includes values for the attributes of the information 
object class to which the entity belongs. 



image box 



The area on a piece of film in which an image appears. 



m - n 



message A data unit of the message exchange protocol exchanged 

between two cooperating DICOM application entities. A 
message is composed of a command stream followed by an 
optional data stream. 

module A group of related information object attributes. 

normalized A type of information object that contains only one 

attribute, as opposed to composite objects that can contain 
many attributes. 
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o-q 



OSI primitives 



presentation 
context 



presentation 
context I.D. 

primitives 

print queue 
profile 



protocol 



Four building blocks of OSI communication (request, indi- 
cation, response, confirmation). 

Contains abstract and transfer syntax; means of making 
sure both sides of communication agree what they're going 
to be doing and how they're going to encode the data. 



Unique identifier for a presentation context 
See OSI primitives. 

A group of images waiting to print. 

A set of operations or services you want to perform. This 
term is similar to an "'application profile," except it is more 
than just the application. It includes: 

• the application 

• the application's interface to the network 

• a set of options. 

A profile forms the basis for the judgement of whether of 
not you conform to DICOM. You don't conform to DICOM 
as an entity; rather to one of the available DICOM profiles. 

Data format; the format data must be in for peer-to-peer 
communication. 



protocol 
data unit 



The block that is used to encode data that passes over an 
association. 



r-s 

service Entity that allows you to perform layer-to-layer communi- 

cation.Could contain routines you call, etc. 
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service class Described in part 4; a structured description of a service 
which is supported by cooperating DICOM application 
entities using specific DICOM commands acting on a 
specific class of information object. 



service 
object pair 



The combination of a service and the type of information 
object upon which it should operate. 



service 
provider 



The sum of the wire, plus all of the lower levels (below the 
application level). See the illustration in Chapter 2. 



t-z 

transfer syntax How objects should be encoded. 

transport Away of moving unstructured data across the network 

connection (e.g., TCP/DP socket or stream). It is a pipeline; you dump 

data in one end and it comes out the other end and vice 

versa. 
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Acronyms 


ACSE 


association control service element 


CMIP 


common management information protocol 


CMIS 


common management information service 


CT 


computed tomography 


DICOM 


Digital Imaging and Communications in Medicine 


DIMSE 


DICOM message service element 


HIS 


Hospital Information System 


niu 


network interface unit 


OSI 


Open Systems Interconnection 


PACS 


Picture Archiving and Communication Systems 




nrntfvnl Hat?* unit 

piuiucui uauL mm 


RIS 


Radiology Information System 


SOP 


service /object pair 


TCP/IP 


Transmission Control Protocol/Internet Protocol 


UID 


unique identifier 
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This appendix contains the index for Understandin g DICOM 3.0. 

a 

A-ASSOCIATE 2-11, 4-36 

About This Book 1-1, 1-3 

Abstract and Transfer Syntax Names 4-36 

Abstract Syntax Options 3-13 

abstract syntax. 3-12 

accepted 2-13 

ACR 1-1 

ACR-NEMA 1-1 

ACSE 2-15, 3-15 

action 4-19 

American College of Radiology 1-1 

application 2-15 

application context 2-16 

application context name UIDs, index of 4-33 

Application Context Names 4-35 

Application Context Usage 4-32 

Application Contexts 3-11 

application entities 2-2 

Application Entity 4-33 

application entity 2-1 

application layer 2-15 

archive 2-14 

ASSOCIATE-AC 2-13 

ASSOCIATE-RJ 2-13 

Association Control Service Elements 2-15 

Association Negotiation 4-16, 4-22, 4-33 

association negotiation 2-14 

Association Services 4-31 

association, setting up 2-16 

Associations 2-14 

attribute tags 4-29 

attribute tags, index of 4-23 
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attribute tags, index to 4-13 
Attributes 3-2 
attributes 3-1 
attributes, creating 4-19 
attributes, getting 4-19 
attributes, setting 4-19 
attributes, types of 3-4 



b 

basic color 4-21 
basic grayscale 4-21 
Behavior 4-16 
big Endian 3-12 
boundaries 2-14 



C 

C2-8 

C++ 2-15, 2-17 

Called Presentation Address 2-17 

Calling Presentation Address 2-17 

CANCEL 3-17 

Character Repertoires 4-25 

character string 3-9 

charts, service parameter 2-7 

CMIP3-15 

CMIS 3-15, 3-17 

Coding Scheme Designators 4-13 

color, basic 4-21 

color, referenced 4-21 

Command Dictionary 4-33 

command set 4-31 

communication primitives 2-5 

communication, lateral 2-1 
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communication, layer-to-layer 2-1 
communication, peer-to-peer 2-1 
communication, vertical 2-1 
communications pipeline 3-12 
composite 3-8 

Composite Information Object Definitions 4-10 

Composite IOD Module Content 4-11 

compressed pixel data 4-27 

Conditional 2-8 

conditional 3-4 

confirmation 2-5, 2-13, 2-20 

Conformance 4-7 

conformance 1-2 

Conformance as an SCP 4-16 

Conformance as an SCU 4-16 

Conformance Requirements 4-8 

Conformance Statement Template 4-8 

Conventions 4-8 

core groups 4-21 

create 4-19 



Data Dictionary 4-29 

Data Element Cross-Reference 4-32 

data element tags, index to 4-28 

data sets, nesting 4-26 

Data Structure and Semantics 4-24 

Data Structures and Encoding 4-24 

Data Units Structure 4-35 

dataset 4-38 

decode 2-19, 3-12 

Default Character Repertoire 4-28 

default character set 4-25 

Definitions 4-5 

device driver 2-15 

Diagnostic 2-13 

DICOM Addressing 4-36 



©1993 Kodak Health Imaging Systems. Inc. 



C-3 



Understanding DICOM 3.0 



DICOM Conformance 4-7 

DICOM Message Service Elements 2-15, 3-15 

DICOM Model of the Real-World 4-10 

DICOM, goal of 1-2 

DIMSE 2-15, 3-15 

DIMSE service group 4-22 

DIMSE Services 4-31 

DIMSE-C 3-16, 3-17,4-31 

DIMSE-C Service Groups 4-18 

DIMSE-N3-16, 3-17,4-31 

e 

ECHO 3-10, 3-17 

Elements of an Information Object Definition 4-10 

Encapsulated Images 4-28 

encode 2-10, 2-11 

encoded pixel data 4-27 

Encoding 3-12 

encoding 4-24, 4-26 

encoding, status type 4-32 

Enumerated Values and Defined Terms 4-25 

equal sign 2-9 

establishing an association 2-17 
event 4-19 
explicit VR 4-26 
extended character sets 4-25 
Extended Negotiation 4-16 
Extended Negotiations 3-14 
extended repertoire 4-25 

f 

film box 3-8, 4-20 

film session 4-20 

film session management 4-19 

film sessions 3-8 
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FIND 3-17 

fixed value 2-8 

format 2-2, 2-3 

forward compatibility 4-37 

framework 2-14 

g 

GET 3-17 
get 4-19 

globally-unique character strings 3-9 
Goals of the DICOM Standard 4-6 
grayscale, basic 4-21 
grayscale, referenced 4-21 
group/element number 4-29 

h 

hand-shaking 4-16 
handshaking 2-14 
headers 3-1 
host name 2-17 

■ 
I 

image box 4-20 
implicit VR 4-26 

Index to Application Context Name UIDs 4-33 
Index to Data Element Tags 4-28 
Index to Transfer Syntax UIDs 4-28 
indication 2-5, 2-6 
Information Model 4-10 
information model 3-1, 3-8 
Information Module Definitions 4-12 
Information Object Definitions 3-2, 4-9, 4-11 
Information Object Identifiers 3-9 
Information Objects 3-1 
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information objects, types of 3-8 
interoperability 1-2 
interrelationships 4-1 
IOD 3-2 

IOD Entity-Relationship Model 4-11 
IOD Module Table 4-11 
ISO 2-15 

■ 

J 

JPEG 4-27 

k 

Key A- ASSOCIATE 2-7 
I 

lateral communication 2-1 
layer 7 2-15 
layers 2-2, 2-3 
library 2-15 
list 3-10 

little Endian 3-12 

m 

M2-8 

mandatory parameters 2-8 

Manual conventions 1-2, 3-1 

Manual, about this 1-2, 3-1 

mapping, of pdu fields 2-13 

Media Storage and File Format 4-38 

Message Exchange 4-30, 4-34 

Message Structure and Command Set 4-31 

message, contents 2-20 

messages 2-5 
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Meta SOP Classes 4-21 
MF2-8 

modalities 2-14, 3-1 
module table 3-5 
Modules 3-5 
Modules in the Spec 3-5 
MOVE 3-17 

n 

N-ACTION3-17 

National Electrical Manufacturer's Association 1-1 
ncoding of Pixel Data 4-27 
N-CREATE 3-17,4-22 
N-DELETE 3-17 
NEMA 1-1 

Nesting of Data Sets 4-26 

Network Communication 4-34 

Network Communication Support Environment 4-34 

network environment 1-2 

network interface 2-2 

N-EVENT 3-17, 4-32 

N-GET 3-17 

normalized 3-8 

Normalized Information Object Definitions 4-12 

normalized service classes 4-19 

Normative References 4-5 

notification 4-19 

N-SET 3-17 

NU2-8 

O 

object-oriented 3-1 

Open System Interconnect 1-1 

operations 3-10 

optional 3-4 
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Optional SOP Classes 4-21 

OSI 1-1,2-15 

OSI communication 2-5 

OSI concepts 2-1 

OSI primitives 2-5 

OSI protocols 3-15 

OSI Upper Layer Profile 4-35 

OSI Upper Layer Service 4-35 

Overlay Encoding Schemes 4-28 

p 
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packet 3-13 
PACS 1-2, 3-8 
parameters 2-5 
parameters, mandatory 2-8 
parameters, types of 2-8 
Patient 3-10 
patient 3-10 

Patient Management Service Class 4-19 

Patient Orientation 4-13 

Patient Root SOP Class Group 4-18 

Patient/Study Only SOP Class Group 4-18 

P-Data 4-33, 4-36 

pdu 2-10 

pdu fields 2-11 

pdu fields, mapping 2-13 

pdu table 2-13 

peer-to-peer 2-1 

pipeline 2-16, 3-12 

pixel data 4-21 

pixel data, encoding 4-27 

Pointers 3-9 

Point-to-Point Communication 4-37 

port number 2-17 

presentation context 3-11 

Presentation Context Def. List Results 2-13 

Presentation Contexts 3-12 
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presentation contexts 2-16 

presentation ID 3-13 

primitives 2-5 

Print Management 3-10 

Print Management Conformance 4-20 

Print Management Meta SOP Classes 4-21 

Print Management Model 4-19 

Print Management SCU Session 4-23 

Print Management Service Class 4-19 

print management service class 4-20 

Print Management SOP Class Definitions 4-22 

print process 4-19 

print session, status of 4-19 

printers 3-10 

Privately Defined Unique Identifier 4-28 

protocol 2-3 

protocol data units 2-10 

Protocol Formats 2-10 

Protocol Formats in the Spec 2-11 

protocol spec 4-31 

protocol specification 3-17, 3-18 

protocols 2-2, 2-14 

protocols, definitions 2-2 



Query/Retrieve 3-10 

Query/Retrieve information Model Definition 4-17 
Query/Retrieve Service Class 4-17 
queue management 4-19 
Quick Reference 4-2 



r 

real- world objects 3-8 
receiving AE title 2-16 
referenced color 4-21 
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referenced grayscale 4-21 

Registry of DICOM Unique Identifiers 4-29 

rejected 2-13 

Relationships of Parts of the Standard 4-6 

Repeating Groups 4-26 

request 2-5 

request message 2-5 

requesting AE title 2-16 

required 3-4 

respond 2-5 

Result 2-13 

Result Source 2-13 

Results 3-10 

results 3-10 

Results Management Service Class 4-19 
Retired Data Elements 4-26 
retrieve 3-10 
routines 2-2, 2-15 
RQ2-13 

S 

Sample Conformance Statement 4-8 

Scope and Field of Application 4-5 

SCU4-16 

semantics 4-24 

SEN 3-17 

SEND 3-10 

sequencing spec 4-31 

sequencing specification 3-18 

sequencing specification ( 3-17 

service 2-2 

service class 3-12 

Service Class Definitions 4-14 

Service Class Specifications 4-14 

Service Classes 3-10 

Service Context 4-30 

service element 2-3 
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service elements 2-2 
Service Parameters 2-5 
service parameters 2-6, 2-10 
Service Parameters in the Spec 2-7 
service provider 2-3 
service spec 4-31 
service specification 3-17, 3-18 
service user 2-3 

Service/Object Pair Instance 3-11 
Service/Object Pairs 3-11 
services 2-6, 2-14 
services, implementation 2-2 
set 4-19 

Setting up an Association 2-16 

socket 2-16 

SOP 3-11 

SOP class 3-12 

SOP Class Definitions 4-18 

Specialized Conformance 4-17 

Standard Query/Retrieve Information Models 4-17 

Standard SOP Classes 4-17 

State Machine 4-35 

status 3-10 

Status Type Encoding 4-32 
Storage 3-10 

Storage Service Class 4-15 
Storage service class 3-14 
STORE 3-17 
stream 2-16 
studies 3-10,4-19 
Study 3-10,4-19 

Study Content/Notification Service Class 4-19 
Study Management Service Class 4-19 
Study Root SOP Class Group 4-18 
Symbols and Abbreviations 4-5 
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TCP host name 2-17 
TCP socket 2-2 

TCP, transport service provided by 4-35 

TCP/IP 2-15 

TCP/IP socket 3- 11 

TCP/IP upper layer protocol 4-35 

The Data Set 4-26 

The Service Provider 2-2 

Transfer Syntax 4-27 

transfer syntax 3-12 

Transfer Syntax Specifications 4-27 

transfer syntax UIDs, index to 4-28 

transport connection 2-18 

transport connections 3-11 

Transport Service Provided by TCP 4-35 

Types of Attributes 3-4 

Types ofDIMSEs 3-16 

Types of Information Objects 3-8 

Types of Parameters 2-8 

U 

U2-8 
UF 2-8 
UID 3-13 

Unique Identifier Registration Process 4-28 

Unique Identifiers (UIDs) 4-27 

unique identifiers, registry of 4-29 

unstructured data 2-16, 3-11 

Upper Layer Protocol for TCP/IP 4-35 

Upper Layer Protocol for TCP/IP State Machine 4-35 

User option 2-8 
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V 

Value 3-2, 4-26 
Value Encoding 4-25 
value multiplicity 4-29 

Value Multiplicity (VM) and Delimitation 4-26 

value representation 4-29 

Value Representation (VR) 4-25 

values 3-3 

Verification 3-10 

Verification Service Class 4-15 

vertical communication 2-1 

W - Z 

why the new standard? 1-2 
wire 2-2 
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